Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAPaJBx5aMVR3eA2XhwhSd34CXO6zN_YOon8ycS77W_=moT293w@mail.gmail.com>
References: 
 <CAPaJBx5aMVR3eA2XhwhSd34CXO6zN_YOon8ycS77W_=moT293w@mail.gmail.com>
Date: Wed, 3 Jul 2013 17:37:52 +0100
Message-ID: 
 <CABvT1DHB8DkvSaE=UwiLn96UtEv366tEkHS11PweWFZvZeJ-6w@mail.gmail.com>
Subject: Re: [RELEASE][PROPOSAL] New release schedule
From: Robert Newson <rnewson@apache.org>
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

+1. Also, the 24th of July is my birthday so I might not vote on the
day itself. Don't be angry.

B.


On 3 July 2013 17:13, Noah Slater <nslater@apache.org> wrote:
> Hey folks,
>
> I've been doing a bit of thinking about the way we handle our new timed
> based released, and I've come to the conclusion that doing a vote on the
> 3rd Tuesday of every month is a flawed approach.
>
> There are delays in testing, and oftentimes multiple vote rounds. This will
> consistently result in the situation where we are doing the actual release
> several weeks behind schedule. The result being that, according to the
> calendar, I would be doing another vote perhaps a week, or even days after
> the release. This clearly makes no sense.
>
> So, I am proposing that we attempt to do a new release four weeks after the
> last release.
>
> i.e. We released 1.3.1 1 week ago, so I am proposing that we attempt
> another release in three weeks.
>
> This means that even if it takes us several weeks to do the next one, we
> will then set a 4 week timer at whatever point we manage to make the
> successful release.
>
> I believe this properly accounts for the fact that we are a volunteer
> project, and that sometimes, things just take a while. But it also keeps us
> on a time based schedule.
>
> One other change I am proposing: I think that in three weeks, we should cut
> whatever is ready. If that means a major point revision, so be it. Minor,
> so be it. Patch, so be it. Whatever is ready. No artificial "patch
> release", "patch release", "feature release" dance.
>
> Assuming nobody objects, or has a better way of doing it, I will proceed
> with this idea.
>
> You can consider this notice that I plan to start a release vote thread on
> the Tuesday the 24th of July. So you have three weeks to get your features
> into master.
>
> Thanks,
>
> --
> NS