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. _______________________________________________ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
