couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: [PROPOSAL] Official roadmap, and merge procedure
Date Thu, 21 Jun 2012 14:19:08 GMT

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 <nslater@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 <jan@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
>>> --
>>> 
>>> 


Mime
View raw message