bump.
On Mon, Jun 18, 2012 at 10:29 AM, Benoit Chesneau <bchesn...@gmail.com> 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. > > *) 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. > > *) 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 > > *) 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. > > Anyway hope we can answer to these questions. > > - benoît
