[etherlab-dev] ethercat-1.5: Various issues

[Gavin Lambert]

A few days ago, quoth I:
> I'm planning to set up a forked repository on SF consisting of the
> current 1.5.2 plus several of the patches I've submitted in the past, 
> in the hopes that maybe it'll be easier for IgH to do an hg pull 
> rather than applying a patch from a mailing list

I've been playing around with it for a little bit, but I'm not sure the
merge-request tools on SF are really up to the job yet.

Also I'm more familiar with Git than Mercurial, and the Git code-sharing
pattern of "fork, branch, commit, pull request, delete" doesn't seem to map
well to Mercurial, since it has very permanent branches that refuse to die
after they're merged.

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?)

Another possibility might be to use the SF-provided Wiki pages or Tickets to
keep track of contributed patches, although that might require some
permission changes to let non-members edit the wiki page.