Proposal: fixed release schedule

[Ryan King <ry...@twitter.com>]

I think many believe that shipping 0.7 took longer than it should.
Rather than going into why that happened, I'd like to propose a better
way to move forward that will hopefully allow us to ship on a more
predictable schedule. This proposal is heavily influenced by the
google chrome release process:

http://www.scribd.com/doc/46659928/Chrome-Release-Cycle-12-16-2010'

..which is heavily influenced by how large websites deploy code
(everyone close to trunk, hide incomplete changes behind configuration
flags, etc.)

I'm not saying we should adopt this process as-is, but some aspects of
it seem like they would be valuable–

# Fixed schedule

We should set a fixed schedule and stick to it. Anything features not
ready at branch time won't make it and will be disabled in the stable
branch.

# Trunk-first

Everyone on chrome commits to trunk first. I think the important
change we could make is to keep everyone closer to trunk. We spend a
good deal of effort back-porting patches between major versions. I
think we should make the major versions less different. This would
mean letting them live for shorter amounts of time and possibly making
them bugfix only. Currently we add new features in stable branches,
but I think if we made the major release schedule more predictable
people would be more comfortable with letting their new feature wait
until the next major version.

We should be more liberal about committing things to trunk early and
iterating on them there (rather than iterating on them in patches). If
the features are unstable we can either hide them behind configuration
flags or remove them when we cut a stable branch.

# Automate all tests

I think the only way that we can keep people close to trunk and stay
stable is to build automated tests for *everything*. All code should
be exercised by thorough unit tests and distributed black-box tests.
Every regression should get a test.


Chrome has a 6 week cycle. I think ours would be more like 4 months
for major releases.

Whatever we do, I think the schedule needs to be more predictable,
which means that the contents of each release will be less predictable
(since its "whatever's ready at the appointed time"). Like the Chrome
presentation mentioned the idea isn't raw speed, but predictable
release schedules.

Feedback please.

-ryan

Re: Proposal: fixed release schedule

[Eric Evans <ee...@rackspace.com>]

On Thu, 2011-01-20 at 21:14 +0000, Stephen Connolly wrote:
> so to be clear, april 9th is feature complete for 0.8.0 and then start
> stabilisation... 

Yes

> ...and when might we see a 0.7.1

Before then.  Well before.  Soon.


-- 
Eric Evans
eevans@rackspace.com

Re: Proposal: fixed release schedule

[Stephen Connolly <st...@gmail.com>]

so to be clear, april 9th is feature complete for 0.8.0 and then start
stabilisation... and when might we see a 0.7.1

or am I completely confused?

...

trying to plan splitting the jar into parts, and delivering ever build
tweaks for allowing abny dev to push release to central repository ;-)

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 20 Jan 2011 16:37, "Eric Evans" <ee...@rackspace.com> wrote:
> On Wed, 2011-01-19 at 10:29 -0600, Jonathan Ellis wrote:
>> On Tue, Jan 18, 2011 at 12:36 PM, Eric Evans <ee...@rackspace.com>
wrote:
>> > The discussion seems to be petering out and I wonder if that means
folks
>> > are still trying to wrap their heads around everything, or if we have
>> > consensus.
>> >
>> > If we're in agreement on 4 months between releases, and
feature-freezing
>> > branches in the run-up, then that would leave us with say 7 weeks (give
>> > or take) to land everything in trunk that we expect in the next release
>> > (and I would think that at this point we'd at least have a good idea
>> > what that'd be).
>>
>> Sounds good.
>>
>> I've assigned to the Riptano/Datastax team the issues we can get to in
>
> OK, then I'm going to assume we have consensus on this.
>
> So again, we released on Jan 9th, 4 months (nominally) would give us a
> release date of May 9th. We need a few weeks for testing and bug
> fixing, say time enough for a couple beta iterations, so let's set a
> tentative date of April 9 to branch, (just under 7 weeks from now).
>
> As of right now I see 71 issues marked 0.8. I haven't been through all
> of them, some are trivial or have patches attached, but some are no
> doubt unrealistic considering the time-line.
>
> For any issues you're championing, please take some time over the next
> couple of weeks to make sure the ones marked fixfor-0.8 match what you
> can accomplish before we branch.
>
> Is that reasonable to everyone?
>
> --
> Eric Evans
> eevans@rackspace.com
>

Re: Proposal: fixed release schedule

[Eric Evans <ee...@rackspace.com>]

On Thu, 2011-01-20 at 10:19 -0800, Ryan King wrote:
> Seems reasonable to me, though I think the release date can be a bit
> more flexible (while the freeze date shouldn't be). In other words, if
> we feature freeze and branch on April 9th, then we're ready to ship
> before May 9th, we should just go ahead and ship.

I'm more worried about the inverse (the date slipping because of bugs),
but sure.

> I'm guessing that we'll have to cut a bunch of scope in order to make
> this happen. 

Yes.

-- 
Eric Evans
eevans@rackspace.com

Re: Proposal: fixed release schedule

[Clint Byrum <cl...@ubuntu.com>]

On Thu, 2011-01-20 at 10:19 -0800, Ryan King wrote:
> On Thu, Jan 20, 2011 at 8:39 AM, Eric Evans <ee...@rackspace.com> wrote:
> > On Wed, 2011-01-19 at 10:29 -0600, Jonathan Ellis wrote:
> >> On Tue, Jan 18, 2011 at 12:36 PM, Eric Evans <ee...@rackspace.com> wrote:
> >> > The discussion seems to be petering out and I wonder if that means folks
> >> > are still trying to wrap their heads around everything, or if we have
> >> > consensus.
> >> >
> >> > If we're in agreement on 4 months between releases, and feature-freezing
> >> > branches in the run-up, then that would leave us with say 7 weeks (give
> >> > or take) to land everything in trunk that we expect in the next release
> >> > (and I would think that at this point we'd at least have a good idea
> >> > what that'd be).
> >>
> >> Sounds good.
> >>
> >> I've assigned to the Riptano/Datastax team the issues we can get to in
> >
> > OK, then I'm going to assume we have consensus on this.
> >
> > So again, we released on Jan 9th, 4 months (nominally) would give us a
> > release date of May 9th.  We need a few weeks for testing and bug
> > fixing, say time enough for a couple beta iterations, so let's set a
> > tentative date of April 9 to branch, (just under 7 weeks from now).
> >
> > As of right now I see 71 issues marked 0.8.  I haven't been through all
> > of them, some are trivial or have patches attached, but some are no
> > doubt unrealistic considering the time-line.
> >
> > For any issues you're championing, please take some time over the next
> > couple of weeks to make sure the ones marked fixfor-0.8 match what you
> > can accomplish before we branch.
> >
> > Is that reasonable to everyone?
> 
> Seems reasonable to me, though I think the release date can be a bit
> more flexible (while the freeze date shouldn't be). In other words, if
> we feature freeze and branch on April 9th, then we're ready to ship
> before May 9th, we should just go ahead and ship.

That time isn't just useful for fixing bugs, its for finding them too.

I'd say just let it settle and always release on the planned date. Spend
the extra time writing tests / running tests, fixing minor bugs, or
working on the next set of features for the next release. If you were
talking about releasing months early, that would be something.. but an
extra week of testing means a more stable release most likely, whereas
dropping the release early doesn't really help much.

Re: Proposal: fixed release schedule

[Ryan King <ry...@twitter.com>]

On Thu, Jan 20, 2011 at 8:39 AM, Eric Evans <ee...@rackspace.com> wrote:
> On Wed, 2011-01-19 at 10:29 -0600, Jonathan Ellis wrote:
>> On Tue, Jan 18, 2011 at 12:36 PM, Eric Evans <ee...@rackspace.com> wrote:
>> > The discussion seems to be petering out and I wonder if that means folks
>> > are still trying to wrap their heads around everything, or if we have
>> > consensus.
>> >
>> > If we're in agreement on 4 months between releases, and feature-freezing
>> > branches in the run-up, then that would leave us with say 7 weeks (give
>> > or take) to land everything in trunk that we expect in the next release
>> > (and I would think that at this point we'd at least have a good idea
>> > what that'd be).
>>
>> Sounds good.
>>
>> I've assigned to the Riptano/Datastax team the issues we can get to in
>
> OK, then I'm going to assume we have consensus on this.
>
> So again, we released on Jan 9th, 4 months (nominally) would give us a
> release date of May 9th.  We need a few weeks for testing and bug
> fixing, say time enough for a couple beta iterations, so let's set a
> tentative date of April 9 to branch, (just under 7 weeks from now).
>
> As of right now I see 71 issues marked 0.8.  I haven't been through all
> of them, some are trivial or have patches attached, but some are no
> doubt unrealistic considering the time-line.
>
> For any issues you're championing, please take some time over the next
> couple of weeks to make sure the ones marked fixfor-0.8 match what you
> can accomplish before we branch.
>
> Is that reasonable to everyone?

Seems reasonable to me, though I think the release date can be a bit
more flexible (while the freeze date shouldn't be). In other words, if
we feature freeze and branch on April 9th, then we're ready to ship
before May 9th, we should just go ahead and ship.

I'm guessing that we'll have to cut a bunch of scope in order to make
this happen.

-ryan

Re: Proposal: fixed release schedule

[Eric Evans <ee...@rackspace.com>]

On Wed, 2011-01-19 at 10:29 -0600, Jonathan Ellis wrote:
> On Tue, Jan 18, 2011 at 12:36 PM, Eric Evans <ee...@rackspace.com> wrote:
> > The discussion seems to be petering out and I wonder if that means folks
> > are still trying to wrap their heads around everything, or if we have
> > consensus.
> >
> > If we're in agreement on 4 months between releases, and feature-freezing
> > branches in the run-up, then that would leave us with say 7 weeks (give
> > or take) to land everything in trunk that we expect in the next release
> > (and I would think that at this point we'd at least have a good idea
> > what that'd be).
> 
> Sounds good.
> 
> I've assigned to the Riptano/Datastax team the issues we can get to in

OK, then I'm going to assume we have consensus on this.

So again, we released on Jan 9th, 4 months (nominally) would give us a
release date of May 9th.  We need a few weeks for testing and bug
fixing, say time enough for a couple beta iterations, so let's set a
tentative date of April 9 to branch, (just under 7 weeks from now).

As of right now I see 71 issues marked 0.8.  I haven't been through all
of them, some are trivial or have patches attached, but some are no
doubt unrealistic considering the time-line.

For any issues you're championing, please take some time over the next
couple of weeks to make sure the ones marked fixfor-0.8 match what you
can accomplish before we branch.

Is that reasonable to everyone?

-- 
Eric Evans
eevans@rackspace.com

Re: Proposal: fixed release schedule

[Jonathan Ellis <jb...@gmail.com>]

On Tue, Jan 18, 2011 at 12:36 PM, Eric Evans <ee...@rackspace.com> wrote:
> The discussion seems to be petering out and I wonder if that means folks
> are still trying to wrap their heads around everything, or if we have
> consensus.
>
> If we're in agreement on 4 months between releases, and feature-freezing
> branches in the run-up, then that would leave us with say 7 weeks (give
> or take) to land everything in trunk that we expect in the next release
> (and I would think that at this point we'd at least have a good idea
> what that'd be).

Sounds good.

I've assigned to the Riptano/Datastax team the issues we can get to in
that time frame.

-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of Riptano, the source for professional Cassandra support
http://riptano.com

Re: Proposal: fixed release schedule

[Eric Evans <ee...@rackspace.com>]

On Fri, 2011-01-14 at 13:11 -0600, Eric Evans wrote:
> > Everyone on chrome commits to trunk first. I think the important
> > change we could make is to keep everyone closer to trunk. We spend a
> > good deal of effort back-porting patches between major versions. I
> > think we should make the major versions less different. This would
> > mean letting them live for shorter amounts of time and possibly 
> > making them bugfix only. Currently we add new features in stable 
> > branches, but I think if we made the major release schedule more 
> > predictable people would be more comfortable with letting their new 
> > feature wait until the next major version.
> 
> I'll call your keep-close-to-trunk, and raise you a:
> 
> *  branch as soon as all planned features land in trunk
> *  iteratively release betas w/ bug-fixes only
> *  release candidates are actual candidates for the final (not
> releases)
> 
> The time between creating the branch and making the release should be
> as short as practical, and there should be no backward incompatible
> changes between the first beta, and final release.

The discussion seems to be petering out and I wonder if that means folks
are still trying to wrap their heads around everything, or if we have
consensus.

If we're in agreement on 4 months between releases, and feature-freezing
branches in the run-up, then that would leave us with say 7 weeks (give
or take) to land everything in trunk that we expect in the next release
(and I would think that at this point we'd at least have a good idea
what that'd be).


-- 
Eric Evans
eevans@rackspace.com

Re: Proposal: fixed release schedule

[Clint Byrum <cl...@ubuntu.com>]

On Fri, 2011-01-14 at 13:11 -0600, Eric Evans wrote:
> On Thu, 2011-01-13 at 14:32 -0800, Ryan King wrote:
> > # Fixed schedule
> > 
> > We should set a fixed schedule and stick to it. Anything features not
> > ready at branch time won't make it and will be disabled in the stable
> > branch.
> 
> In general, I agree, if we want a cadence, we're going to have to exert
> some pressure to release at an agreed upon time.  But, as Jonathan says,
> we need to be flexible.
> 
> Even on this project, there have been times when we've put a clock on a
> stable release, and had problems with people rushing in poorly tested
> changes.
> 

The Ubuntu project has only slipped (to my knowledge) once in nearly 7
years of 6 month cadence releases. The key is to respect feature
freezes, and get everybody on board with slowing or even halting their
feature work at those freezes to fix the bugs or even revert things that
have panned out poorly.

Currently Ubuntu's feature freeze [1] is at week 19 of the 28 week
release cycle [2] (they normally are 26 weeks long but 10.10 was
shortened for the 10-10-10 release date).

Exceptions to the feature freeze can be approved by a board, but must
have justification such as when reverting will cause more pain than just
finishing it, or that the feature can be disabled by default without
breaking other pieces so as not to block the release.

I'd recommend that any cadence based release discussion at least examine
Ubuntu's implementation and experiences given how successful it has
been.

The benefits to a large user base are huge. As consumers of Cassandra
mature and the coupling with other software becomes tighter, it will be
much more important that users can at least have some idea of release
timing, even if they can't guarantee that the feature they want goes in.

--
1. https://wiki.ubuntu.com/FeatureFreeze
2. https://wiki.ubuntu.com/NattyReleaseSchedule

Re: Proposal: fixed release schedule

[Eric Evans <ee...@rackspace.com>]

On Thu, 2011-01-13 at 14:32 -0800, Ryan King wrote:
> # Fixed schedule
> 
> We should set a fixed schedule and stick to it. Anything features not
> ready at branch time won't make it and will be disabled in the stable
> branch.

In general, I agree, if we want a cadence, we're going to have to exert
some pressure to release at an agreed upon time.  But, as Jonathan says,
we need to be flexible.

Even on this project, there have been times when we've put a clock on a
stable release, and had problems with people rushing in poorly tested
changes.

> # Trunk-first
> 
> Everyone on chrome commits to trunk first. I think the important
> change we could make is to keep everyone closer to trunk. We spend a
> good deal of effort back-porting patches between major versions. I
> think we should make the major versions less different. This would
> mean letting them live for shorter amounts of time and possibly making
> them bugfix only. Currently we add new features in stable branches,
> but I think if we made the major release schedule more predictable
> people would be more comfortable with letting their new feature wait
> until the next major version.

I'll call your keep-close-to-trunk, and raise you a:

*  branch as soon as all planned features land in trunk
*  iteratively release betas w/ bug-fixes only
*  release candidates are actual candidates for the final (not releases)

The time between creating the branch and making the release should be as
short as practical, and there should be no backward incompatible changes
between the first beta, and final release.

> We should be more liberal about committing things to trunk early and
> iterating on them there (rather than iterating on them in patches). If
> the features are unstable we can either hide them behind configuration
> flags or remove them when we cut a stable branch.

As Jonathan said elsewhere in this thread, Git is finally within reach,
and would solve many of the current technical limitations with our
current process.  I'd favor that as a first-step.

> # Automate all tests
> 
> I think the only way that we can keep people close to trunk and stay
> stable is to build automated tests for *everything*. All code should
> be exercised by thorough unit tests and distributed black-box tests.
> Every regression should get a test.

Absolutely.

> Chrome has a 6 week cycle. I think ours would be more like 4 months
> for major releases.
> 
> Whatever we do, I think the schedule needs to be more predictable,
> which means that the contents of each release will be less predictable
> (since its "whatever's ready at the appointed time"). Like the Chrome
> presentation mentioned the idea isn't raw speed, but predictable
> release schedules.

Yeah.  Sounds good.

-- 
Eric Evans
eevans@rackspace.com

Re: Proposal: fixed release schedule

[Ryan King <ry...@twitter.com>]

On Thu, Jan 13, 2011 at 4:04 PM, Jonathan Ellis <jb...@gmail.com> wrote:
> On Thu, Jan 13, 2011 at 2:32 PM, Ryan King <ry...@twitter.com> wrote:
>> # Fixed schedule
>>
>> We should set a fixed schedule and stick to it. Anything features not
>> ready at branch time won't make it and will be disabled in the stable
>> branch.
>
> I like this idea, as long as we're willing to be flexible when
> warranted.  Sometimes it is less work to finish a feature, than to rip
> it out.

Two things:

First, I think a key part of how you make this successful (both for
Chome and for continuously deployed software like large services) is
that non-trivial changes almost always have to be hidden behind flags
until they're ready for wide use.

Second, I think this will only work well if we are somewhat strict about it.

>> # Trunk-first
>>
>> Everyone on chrome commits to trunk first.
>
> I suppose that's fine if it works for them, but it's not The One True
> Way.  Changes that affect both stable and trunk branches should really
> be applied to stable first and merged forward.  Here is a good
> presentation explaining why:
> http://video.google.com/videoplay?docid=-577744660535947210.
>
> Another reason is that committing fixes to a stable branch and then
> using "svn merge branch" from trunk means svn tracks everything that
> has been committed to branch and not yet to trunk, and merges it in.
> So it protects us somewhat against people committing a fix to trunk,
> then forgetting to commit to the stable branch.

I guess I don't care as much about the mechanics of this as the
intent– which is to keep stable and trunk closer together. And to keep
people working on a more common base.

>> I think the important
>> change we could make is to keep everyone closer to trunk. We spend a
>> good deal of effort back-porting patches between major versions. I
>> think we should make the major versions less different. This would
>> mean letting them live for shorter amounts of time and possibly making
>> them bugfix only.
>
> In theory I agree (see: policy for 0.4 and 0.5 stable releases).  In
> practice, users overwhelmingly wanted more than that in between major
> releases.  Not that users are always right, but this is an area where
> I think they are worth listening to. :)

Perhaps minor things are worth adding in a stable branch. I think this
is an area where judgement can come into play.

>> I think if we made the major release schedule more predictable
>> people would be more comfortable with letting their new feature wait
>> until the next major version.
>
> In my experience it's not the unpredictability as much as "I'm feeling
> this pain Right Now and four months is too long to wait."

Perhaps waiting is the biggest pain for users, but for developers
unpredictability is just as big a problem. If I don't know when
release N+1 is going to happen I might try to hurry to get my feature
into release N. If I have confidence that release N+1 will come
promptly at a scheduled time I can set my expectation appropriately.

>> We should be more liberal about committing things to trunk early and
>> iterating on them there (rather than iterating on them in patches).
>
> I agree in the sense that we were too slow to branch 0.7 to have an
> open trunk to start work on.
>
> But I disagree in the sense that we shouldn't be committing
> works-in-progress to trunk because that becomes the baseline everyone
> else has to develop from.  (I know at least one team with a nontrivial
> patchset against trunk from the 0.7 beta1 timeframe, back when it had
> the Clock struct that we committed prematurely.)

So we made a mistake once. :) I think committing large changes in
smaller pieces will be a net positive, even if it occasionally trips
us up. For example, I think work on counters between our team and
Sylvain has improved dramatically once we committed 1072.

> IMO the right fix is to help the ASF make git an option; in the
> meantime the best workaround is a git-based workflow with
> git-jira-attacher and git-am as described in
> http://spyced.blogspot.com/2009/06/patch-oriented-development-made-sane.html
> and http://wiki.apache.org/cassandra/GitAndJIRA.

So you're proposing that we use git to keep long-running feature branches?

>> # Automate all tests
>>
>> I think the only way that we can keep people close to trunk and stay
>> stable is to build automated tests for *everything*. All code should
>> be exercised by thorough unit tests and distributed black-box tests.
>> Every regression should get a test.
>
> Agreed.
>
>> Chrome has a 6 week cycle. I think ours would be more like 4 months
>> for major releases.
>
> Four months feels about right to me, too, although for 0.7 + 1 I'd
> like to make it a bit shorter (beginning of April?) since we have
> several features (1072 being the most prominent) that just barely
> missed 0.7.

Like I said, we're going to have to figure out the right pace, but we
should try and stick to it.

>> Whatever we do, I think the schedule needs to be more predictable,
>> which means that the contents of each release will be less predictable
>> (since its "whatever's ready at the appointed time"). Like the Chrome
>> presentation mentioned the idea isn't raw speed, but predictable
>> release schedules.
>
> I agree.  At the least, I think it's worth trying.

Good.

-ryan

Re: Proposal: fixed release schedule

[Jonathan Ellis <jb...@gmail.com>]

On Thu, Jan 13, 2011 at 2:32 PM, Ryan King <ry...@twitter.com> wrote:
> # Fixed schedule
>
> We should set a fixed schedule and stick to it. Anything features not
> ready at branch time won't make it and will be disabled in the stable
> branch.

I like this idea, as long as we're willing to be flexible when
warranted.  Sometimes it is less work to finish a feature, than to rip
it out.

> # Trunk-first
>
> Everyone on chrome commits to trunk first.

I suppose that's fine if it works for them, but it's not The One True
Way.  Changes that affect both stable and trunk branches should really
be applied to stable first and merged forward.  Here is a good
presentation explaining why:
http://video.google.com/videoplay?docid=-577744660535947210.

Another reason is that committing fixes to a stable branch and then
using "svn merge branch" from trunk means svn tracks everything that
has been committed to branch and not yet to trunk, and merges it in.
So it protects us somewhat against people committing a fix to trunk,
then forgetting to commit to the stable branch.

> I think the important
> change we could make is to keep everyone closer to trunk. We spend a
> good deal of effort back-porting patches between major versions. I
> think we should make the major versions less different. This would
> mean letting them live for shorter amounts of time and possibly making
> them bugfix only.

In theory I agree (see: policy for 0.4 and 0.5 stable releases).  In
practice, users overwhelmingly wanted more than that in between major
releases.  Not that users are always right, but this is an area where
I think they are worth listening to. :)

> I think if we made the major release schedule more predictable
> people would be more comfortable with letting their new feature wait
> until the next major version.

In my experience it's not the unpredictability as much as "I'm feeling
this pain Right Now and four months is too long to wait."

> We should be more liberal about committing things to trunk early and
> iterating on them there (rather than iterating on them in patches).

I agree in the sense that we were too slow to branch 0.7 to have an
open trunk to start work on.

But I disagree in the sense that we shouldn't be committing
works-in-progress to trunk because that becomes the baseline everyone
else has to develop from.  (I know at least one team with a nontrivial
patchset against trunk from the 0.7 beta1 timeframe, back when it had
the Clock struct that we committed prematurely.)

IMO the right fix is to help the ASF make git an option; in the
meantime the best workaround is a git-based workflow with
git-jira-attacher and git-am as described in
http://spyced.blogspot.com/2009/06/patch-oriented-development-made-sane.html
and http://wiki.apache.org/cassandra/GitAndJIRA.

> # Automate all tests
>
> I think the only way that we can keep people close to trunk and stay
> stable is to build automated tests for *everything*. All code should
> be exercised by thorough unit tests and distributed black-box tests.
> Every regression should get a test.

Agreed.

> Chrome has a 6 week cycle. I think ours would be more like 4 months
> for major releases.

Four months feels about right to me, too, although for 0.7 + 1 I'd
like to make it a bit shorter (beginning of April?) since we have
several features (1072 being the most prominent) that just barely
missed 0.7.

> Whatever we do, I think the schedule needs to be more predictable,
> which means that the contents of each release will be less predictable
> (since its "whatever's ready at the appointed time"). Like the Chrome
> presentation mentioned the idea isn't raw speed, but predictable
> release schedules.

I agree.  At the least, I think it's worth trying.

-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of Riptano, the source for professional Cassandra support
http://riptano.com

Re: Proposal: fixed release schedule

[Ryan King <ry...@twitter.com>]

To be more clear, here's what I think is broken in the current release planning:

1. The dates are wildly unpredictable
2. People aren't allowed to work against trunk on features for
multiple iterations (see #1072)
3. Stable branches diverge too much, causing duplicated effort. (we
essentially implemented #1072 twice for 0.6 and 0.7)
4, back porting features is risky and causes bugs, esp with the
limited QA available

-ryan

On Thu, Jan 13, 2011 at 2:32 PM, Ryan King <ry...@twitter.com> wrote:
> I think many believe that shipping 0.7 took longer than it should.
> Rather than going into why that happened, I'd like to propose a better
> way to move forward that will hopefully allow us to ship on a more
> predictable schedule. This proposal is heavily influenced by the
> google chrome release process:
>
> http://www.scribd.com/doc/46659928/Chrome-Release-Cycle-12-16-2010'
>
> ..which is heavily influenced by how large websites deploy code
> (everyone close to trunk, hide incomplete changes behind configuration
> flags, etc.)
>
> I'm not saying we should adopt this process as-is, but some aspects of
> it seem like they would be valuable–
>
> # Fixed schedule
>
> We should set a fixed schedule and stick to it. Anything features not
> ready at branch time won't make it and will be disabled in the stable
> branch.
>
> # Trunk-first
>
> Everyone on chrome commits to trunk first. I think the important
> change we could make is to keep everyone closer to trunk. We spend a
> good deal of effort back-porting patches between major versions. I
> think we should make the major versions less different. This would
> mean letting them live for shorter amounts of time and possibly making
> them bugfix only. Currently we add new features in stable branches,
> but I think if we made the major release schedule more predictable
> people would be more comfortable with letting their new feature wait
> until the next major version.
>
> We should be more liberal about committing things to trunk early and
> iterating on them there (rather than iterating on them in patches). If
> the features are unstable we can either hide them behind configuration
> flags or remove them when we cut a stable branch.
>
> # Automate all tests
>
> I think the only way that we can keep people close to trunk and stay
> stable is to build automated tests for *everything*. All code should
> be exercised by thorough unit tests and distributed black-box tests.
> Every regression should get a test.
>
>
> Chrome has a 6 week cycle. I think ours would be more like 4 months
> for major releases.
>
> Whatever we do, I think the schedule needs to be more predictable,
> which means that the contents of each release will be less predictable
> (since its "whatever's ready at the appointed time"). Like the Chrome
> presentation mentioned the idea isn't raw speed, but predictable
> release schedules.
>
> Feedback please.
>
> -ryan
>