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: 
 <CABvT1DHB8DkvSaE=UwiLn96UtEv366tEkHS11PweWFZvZeJ-6w@mail.gmail.com>
References: 
 <CAPaJBx5aMVR3eA2XhwhSd34CXO6zN_YOon8ycS77W_=moT293w@mail.gmail.com>
	<CABvT1DHB8DkvSaE=UwiLn96UtEv366tEkHS11PweWFZvZeJ-6w@mail.gmail.com>
Date: Wed, 3 Jul 2013 17:46:46 +0100
Message-ID: 
 <CAPaJBx4mkcVp1gz0aSUUAka8-22aAEb0974dYH7f33Rmf5rJrA@mail.gmail.com>
Subject: Re: [RELEASE][PROPOSAL] New release schedule
From: Noah Slater <nslater@apache.org>
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
Content-Type: multipart/alternative; boundary=047d7bdc1238173cb104e09e352e

--047d7bdc1238173cb104e09e352e
Content-Type: text/plain; charset=ISO-8859-1

Hehe...


On 3 July 2013 17:37, Robert Newson <rnewson@apache.org> wrote:

> +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
>


-- 
NS

--047d7bdc1238173cb104e09e352e--