On Jun 18, 2012, at 10:29 , Benoit Chesneau wrote: > On Sat, Jun 16, 2012 at 6:45 PM, Noah Slater <nsla...@tumbolia.org> 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...) >> >> Thanks, >> >> N > > Thanks for these wikis. Roadmap process is good but the merge > procedure is a little obscure.
That's why Noah wrote >> (The last one needs to be fleshed out, a little...) :D > *) What happen in master during the release procedure? Are you > freezing it ? Imo we should freeze it except if we want to reedit the > current nightmare. Freezing the master give the following advantage: > > - focus developers on the release > - make sure anything done for the release will be easily merged in the master. > > Imo this freeze shouldn't be a problem since we have the > topic/features branches to continue devs on other things. or remote > branch. Anyway this should be clear on the wiki. I don't feel strongly in either direction, but I like the benefit of focus on the release branch. Feature development can still happen in branches as you write, it's just that we put the merging to master on hold until we ship the x.0 of the release branch. > *) You're speaking about merge, but what if a bugfix only goes for a > release and doesn't apply to master and other releases branches? I'm > thinking to 2 scenari there: > > - bug only happen in a release branch and has only be raised here. > Where should the bugfix should be applied first? Do we care to try to > merge it in other branches (painful and open the door to other bugs) > - bug is found in the master: what is the procedure to check if this > bu g apply to other branch I think Paul covered this in his last mail. If a bugfix applies to all affected branches, we can just merge that. If it doesn't, the committer(s) can create multiple branches 1234-bugfix-master, 1234-bufix-1.2.0 etc. (I believe dev@ can help with backporting, too). I don't think we need a policy on which branch needs fixing first. Either the bugfix patch applies to all affected branches as is or it doesn't in which case it needs to be back-ported or forward- ported, either of which can be troublesome, so I don't think a procedure can help to mitigate extra work required here. I think that's okay, too. But, I maybe missing something obvious. > *) related to above: release manager: whos is (s)he ? Only one guy? Do > we have like in perl or debian a release manager / major versions ? > > Having one release manager / version would do the trick, since he > would be supposed to know the state of the last version of his release > (1.x, 2.x) ... And how bugs can be applied in. We tend to have a release master per release branch (1.0 was Noah, 1.1. was Robert Newson, etc.) It's a voluntary role, nothing fancy, all you need to do is to volunteer and get some "training" by the existing RMs (Noah, Paul, Robert N.). I think this is roughly what you suggest and I believe we should just keep doing that. It wouldn't hurt though to codify this on the wiki at some point. > Anyway hope we can answer to these questions. I hope this answers your questions :) Cheers Jan --
