Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of bchesneau@gmail.com
 designates 209.85.217.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CA+Y+4453Y9qUcRVh17iaPfjU2G5AHCFC-5AFb4OEwpvVvO-MQw@mail.gmail.com>
References: 
 <CA+Y+4453Y9qUcRVh17iaPfjU2G5AHCFC-5AFb4OEwpvVvO-MQw@mail.gmail.com>
Date: Mon, 18 Jun 2012 10:29:36 +0200
Message-ID: 
 <CAJNb-9rGrwukpbNpe6JavMac6fJCLEWgtpRv5vZHW7-cG7Fpbg@mail.gmail.com>
Subject: Re: [PROPOSAL] Official roadmap, and merge procedure
From: Benoit Chesneau <bchesneau@gmail.com>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 16, 2012 at 6:45 PM, Noah Slater <nslater@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 mast=
er.

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=EEt