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.
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
>> --
>>
>>
