[etherlab-dev] ethercat-1.5: Various issues

[Gavin Lambert]

A few hours ago, quoth I:
> So I thought I'd try asking Florian which method would be preferred for
> submitting code changes (ie. which would be most likely to actually get
> merged to mainline):
>
> 1. Stick with posting patches to the ML and hope they don't fall through
> the cracks.
> 
> 2. Fork, branch, commit, merge-request.  (At least branches can be
> closed later to reduce the clutter a little, although that doesn't help
> SF's repository browser at the moment.)
> 
> 3. Fork, tag, commit, merge-request.  (Tags can kinda be deleted but
> they seem a little awkward for this workflow since they require extra
> commits to
> add/remove/update.)
> 
> 4. Fork, bookmark, commit, mention on ML (because SF's merge-requests
> don't handle bookmarks yet).  (From what I can tell, bookmarks are the
> closest Mercurial equivalent to branches that can be deleted after their
> changes are merged, but SF's UI doesn't yet know they exist.)
> 
> 5. Something else.  (hg bundle maybe?)

6. Fork, commit, merge-request.  (ie. an entire fork/clone per "feature", no
explicit branching)

This actually seems like the easiest model using the existing tools, and
seems to be recommended by quite a few people.  But it makes me cringe
inside.  Especially if you want to submit multiple independent features.