Mailing-List: contact dev-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Message-Id: 
 <1447103211.2465303.434268129.41F392E1@webmail.messagingengine.com>
From: Ariel Weisberg <ariel@weisberg.ws>
To: dev@cassandra.apache.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain
In-Reply-To: 
 <CALamADJ4jqV47zWLgojd1p53JGvT3WY8ZTV2UoKfQSmkgoweoQ@mail.gmail.com>
References: <etPan.5640cb65.215a7309.24e@AY15rMBP.local>
 <CALamADL9VDeLGEigdMLLDEtOsrj4YddARY1vpUWLE9ttQJvhsw@mail.gmail.com>
 <CALdd-ziYxKsqEvcVWRLT=5aAEhHTm5SZo8vqUZmMmK16TzWGbA@mail.gmail.com>
 <CALamADJ4jqV47zWLgojd1p53JGvT3WY8ZTV2UoKfQSmkgoweoQ@mail.gmail.com>
Subject: Re: cassandra-3.1 branch and new merge order
Date: Mon, 09 Nov 2015 16:06:51 -0500

Hi,

What I had thought we were going to do was branch for a feature release
every two months and then backport fixes to the last feature release (or
prior ones) as desired.

So in terms of extra merge effort you only have to backport fixes, and
if we solved the release quality issues this is something that is very
little work. Even if we don't we only have to backport a months worth of
fixes (although I would advocate making it two months). If we do a
feature release every two months that gives us two months to put
together a bug fix release for it without falling behind or supporting
multiple older releases.

I am pretty confident that a month is not enough time to find and fix
the bugs in a release. Not the way we currently operate where activities
are unsynchronized and we don't make an effort to get stuff to "done"
quickly as a default. Instead we opt to have a lot of stuff in flight to
hide the latency of getting things to "done". That is also a problem
when there are dependencies.

TL;DR Even minor stuff stretches out to multiple months.

Another thing that came up is how the release schedule impacts
development work. There were some voices (can't recall who) who thought
that the month after a feature release would only contain bug fix work.
I don't think that makes much sense since you won't even necessarily
know what all the bugs are and you can't leave developers idle waiting
for bugs to come in.

I think we should scheduled feature work and as bugs come in do them
first. I think we should always be doing bugs first and that's how I
schedule my time (actually review, bugs, then new work). If you don't
connect the backpressure from bugs to the rate at which you do new work
you will always end up falling behind or rubber banding and not get the
benefits of passing CI.

Ariel

On Mon, Nov 9, 2015, at 12:23 PM, Jake Luciani wrote:
> I don't think there's anything wrong with it. I just think it's not
> needed.
> 
> - The max someone would wait is 4 weeks and in my mind the feature writer
> is the best person to make the changes to merge the code to the latest
> version.  Vs an unrelated change that may be improperly merged.
> - Today for every change we make we must manually merge on commit every
> time which is error prone, this goes away with a single branch.
> - We historically care about tests in the latest release branch.  We've
> never done a great job fixing issues in the trunk when they happen (look
> at
> cassci trunk vs 3.0 today).  So it's not like we gain anything by keeping
> 2
> branches there.
> - This keeps our testing focus on the task at hand so we dedicate our
> testing time in a given month to the changes of that release and don't
> need
> any parallel runs for features.
> 
> 
> 
> On Mon, Nov 9, 2015 at 12:06 PM, Jonathan Ellis <jbellis@gmail.com>
> wrote:
> 
> > I'm not a huge fan of leaving features to rot unmerged for a couple
> > months.  What is wrong with "new features go to trunk, stable branches get
> > forked at release?"
> >
> > On Mon, Nov 9, 2015 at 10:54 AM, Jake Luciani <jakers@gmail.com> wrote:
> >
> > > Looking back at the tick-tock email chain we never really discussed this.
> > >
> > > Rather than having 3.1 and trunk I think we should have just trunk.
> > >
> > > I'd rather not let features sit in a branch with bugfixes going on top
> > that
> > > can decay.
> > > They should be merged in when it's time to merge features for 3.even,
> > post
> > > 3.odd.
> > >
> > > I know we have features in trunk today that aren't in 3.0 and we probably
> > > shouldn't have done that.
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Mon, Nov 9, 2015 at 11:35 AM, Aleksey Yeschenko <aleksey@apache.org>
> > > wrote:
> > >
> > > > With 3.0.0 vote to be over soon, tick-tock is officially starting, and
> > we
> > > > are creating a new branch for cassandra-3.1 release.
> > > >
> > > > New merge order: cassandra-2.2 -> cassandra-3.0 -> cassandra-3.1 ->
> > trunk
> > > >
> > > > - cassandra-3.0 branch is going to continue representing the 3.0.x
> > series
> > > > of releases (3.0 bugfixes only, as no new feature are supposed to go
> > into
> > > > 3.0.x release series)
> > > > - cassandra-3.1 branch will contain 3.0 bugfixes *only*
> > > > - trunk represents the upcoming cassandra-3.2 release (fixes from 3.1
> > and
> > > > new features)
> > > >
> > > > --
> > > > AY
> > >
> > >
> > >
> > >
> > > --
> > > http://twitter.com/tjake
> > >
> >
> >
> >
> > --
> > Jonathan Ellis
> > Project Chair, Apache Cassandra
> > co-founder, http://www.datastax.com
> > @spyced
> >
> 
> 
> 
> -- 
> http://twitter.com/tjake