On Jun 17, 2012, at 20:48 , Paul Davis wrote: > The only thing I see an issue with is the merge commit policy. > > You'll find quite quickly that you'll have situations that require > merge commits with diff's to work properly. A traditional example is > bug fixes that reach back through many release branches. If the RM > rejects anything that's not a clean merge then what the committer is > required to do is either write three different commits tailored to > each release branch (which defeats the purpose of the merge) or merge > work back to a release branch and then submit the merge commit as a > commit to be merged into the release branch (which makes my brain hurt > just thinking about it). > > If you really want the RM to be a gate keeper/reviewer what I'd > suggest is that we take a hard line against working on master at all. > When we want to submit work we do the email thing that'll include a > list of commits, one per branch. Ie, something like: > > 1234-master-cool > 1234-1.4.x-cool > > And then we do our review dance and CI checks. (Also, if one commit > works on all branches, that's fine, this just allows a degree of > freedom for when things don't apply the same everywhere). Along with > the rational for tests and docs rational for why things are back > ported vs are etc etc should be included in the email to dev@. Also, > we'll want to get a template/example/something up on the net so people > know what to submit when they do submit. > > And the actual push to branches happens with one of the RM's reviewing > it and then doing a rebase onto those branches (and rejecting as > failed). > > This way we have single commits per feature/fix/whatever on all of our > release branches but we allow the committer to produce the commits > that will inevitably have to be tailored to each branch in some cases.
I think we sorta went through this in Dublin, but were a bit handwavey with details. Thanks for writing this up. Could you add a summary or run-book type thing to the Merge_procedure wiki page? Cheers Jan -- > > > > On Sun, Jun 17, 2012 at 11:48 AM, Noah Slater <nsla...@tumbolia.org> wrote: >> Thanks for the comments guys. >> >> Bob was in the room when this proposal was drafted (literally) but Paul is >> our other active release manager, so I want to wait for his review before I >> comment on anything in the thread. I am also interested to hear what Jason >> Smith thinks, and indeed, anyone else from Cloudant, or other downstream >> CouchDB individuals this may effect. If you're interested in helping the >> CouchDB community test CouchDB, through QA, CI, or any other method, then >> your should also chime in here. >> >> On Sun, Jun 17, 2012 at 4:28 PM, Jan Lehnardt <j...@apache.org> wrote: >> >>> >>> On Jun 16, 2012, at 18:45 , Noah Slater wrote: >>> >>>> Devs, >>>> >>>> A few of us met in Dublin recently, and we discussed the project roadmap. >>>> >>>> Key takeaways from that meeting: >>>> >>>> 1. We'd like to proposed formal time-based releases >>>> >>>> >>>> 2. Branch and hack all you like, but if you want to ship something, you >>>> have to submit a merge request to an active release branch. Before you do >>>> this, you should follow a test procedure. And before your request will be >>>> accepted, it will be put through QA by the community. >>>> >>>> >>>> Details of these proposals can be found here: >>>> >>>> http://wiki.apache.org/couchdb/Roadmap_Process >>>> >>>> >>>> http://wiki.apache.org/couchdb/Merge_Procedure >>>> >>>> >>>> Please reply back to this thread with your comments on the proposals. >>>> >>>> (The last one needs to be fleshed out, a little...) >>> >>> In particular this bit: >>> >>>> Feature branches are merged to release branches using 'git merge --no-ff >>> <FEATURE BRANCH>'. This guarantees a merge commit, which are the only kinds >>> of commit that will appear on release branches. If the merge results in >>> conflicts, the release manager rejects the merge commit with an reply to >>> the dev@ thread. If the merge is successful, the release manager should >>> run 'make distcheck' and push the merge upstream if the tests pass. >>> >>> Merges are currently not allowed on release branches and master. IIRC we >>> came up with git merge --no-ff being "safe" to enable, but this currently >>> is still disabled. >>> >>> Cheers >>> Jan >>> -- >>> >>>
