cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh McKenzie <jmcken...@apache.org>
Subject Re: Wrapping up tick-tock
Date Tue, 10 Jan 2017 16:46:21 GMT
>
> I would also propose we move on to 3.10.x bugfix only releases from now
> on, with all new feature development moving to trunk from now on.

You thinking monthly release on that or "as needed"? In theory, monthly
should be easier than previous tick-tock if we're only putting in bugfix or
testfix on the branch.

On Tue, Jan 10, 2017 at 11:41 AM, Aleksey Yeschenko <aleksey@apache.org>
wrote:

> 6 months seems reasonable to me as well.
>
> There seems to be an agreement to halting 3.X on 3.10. I would also propose
> we move on to 3.10.x bugfix only releases from now on, with all new feature
> development moving to trunk from now on.
>
> This should allow us to finally stabilise 3.X so that we can get all test
> jobs to green.
>
> --
> AY
>
> On 10 January 2017 at 16:36:43, Josh McKenzie (jmckenzie@apache.org)
> wrote:
>
> +1 to 6 months.
>
> On Tue, Jan 10, 2017 at 11:32 AM, Jonathan Ellis <jbellis@gmail.com>
> wrote:
>
> > I agree that 6 month seems like a reasonable compromise.
> >
> > On Tue, Jan 10, 2017 at 10:31 AM, Blake Eggleston <beggleston@apple.com>
> > wrote:
> >
> > > I agree that 3.10 should be the last tick-tock release, but I also
> agree
> > > with Jon that we shouldn't go back to yearly-ish releases.
> > >
> > > 6 months has come up several times now as a good cadence for feature
> > > releases, and I think it's a good compromise between the competing
> > > interests of long term support, regular release of features (to prevent
> > > piling on), and effort to release. So +1 to 6 month releases.
> > >
> > > On January 10, 2017 at 10:14:12 AM, Ariel Weisberg (ariel@weisberg.ws)
> > > wrote:
> > >
> > > Hi,
> > >
> > > With yearly releases trunk is going to be a mess when it comes time to
> > > cut a release. Cutting releases is when people start caring whether all
> > > the things in the release are in a finished state. It's when the state
> > > of CI finally becomes relevant.
> > >
> > > If we wait a year we are going to accumulate a years worth of
> unfinished
> > > stuff in a single release. It's more expensive to context switch back
> > > and then address those issues. If we put out large unstable releases it
> > > means time until the features in the release are usable is pushed back
> > > even further since it takes another 6-12 months for the release to
> > > stabilize. Features introduced at the beginning of the cycle will have
> > > to wait 18-24 months before anyone can benefit from them.
> > >
> > > Is the biggest pain point with tick-tock just the elimination of long
> > > term support releases? What is the pain point around release frequency?
> > > Right now people should be using 3.0 unless they need a bleeding edge
> > > feature from 3.X and those people will have to give up something to get
> > > something.
> > >
> > > Ariel
> > >
> > > On Tue, Jan 10, 2017, at 10:29 AM, Jonathan Haddad wrote:
> > > > I don't see why it has to be one extreme (yearly) or another
> (monthly).
> > > > When you had originally proposed Tick Tock, you wrote:
> > > >
> > > > "The primary goal is to improve release quality. Our current major
> “dot
> > > > zero” releases require another five or six months to make them stable
> > > > enough for production. This is directly related to how we pile
> features
> > > > in
> > > > for 9 to 12 months and release all at once. The interactions between
> > the
> > > > new features are complex and not always obvious. 2.1 was no
> exception,
> > > > despite DataStax hiring a full tme test engineering team specifically
> > for
> > > > Apache Cassandra."
> > > >
> > > > I agreed with you at the time that the yearly cycle was too long to
> be
> > > > adding features before cutting a release, and still do now. Instead
> of
> > > > elastic banding all the way back to a process which wasn't working
> > > > before,
> > > > why not try somewhere in the middle? A release every 6 months (with
> > > > monthly bug fixes for a year) gives:
> > > >
> > > > 1. long enough time to stabilize (1 year vs 1 month)
> > > > 2. not so long things sit around untested forever
> > > > 3. only 2 releases (current and previous) to do bug fix support at
> any
> > > > given time.
> > > >
> > > > Jon
> > > >
> > > > On Tue, Jan 10, 2017 at 6:56 AM Jonathan Ellis <jbellis@gmail.com>
> > > wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > We’ve had a few threads now about the successes and failures of
the
> > > > > tick-tock release process and what to do to replace it, but they
> all
> > > died
> > > > > out without reaching a robust consensus.
> > > > >
> > > > > In those threads we saw several reasonable options proposed, but
> from
> > > my
> > > > > perspective they all operated in a kind of theoretical fantasy land
> > of
> > > > > testing and development resources. In particular, it takes around
a
> > > > > person-week of effort to verify that a release is ready. That is,
> > going
> > > > > through all the test suites, inspecting and re-running failing
> tests
> > > to see
> > > > > if there is a product problem or a flaky test.
> > > > >
> > > > > (I agree that in a perfect world this wouldn’t be necessary because
> > > your
> > > > > test ci is always green, but see my previous framing of the perfect
> > > world
> > > > > as a fantasy land. It’s also worth noting that this is a common
> > problem
> > > > > for large OSS projects, not necessarily something to beat ourselves
> > up
> > > > > over, but in any case, that's our reality right now.)
> > > > >
> > > > > I submit that any process that assumes a monthly release cadence
is
> > not
> > > > > realistic from a resourcing standpoint for this validation.
> Notably,
> > we
> > > > > have struggled to marshal this for 3.10 for two months now.
> > > > >
> > > > > Therefore, I suggest first that we collectively roll up our sleeves
> > to
> > > vet
> > > > > 3.10 as the last tick-tock release. Stick a fork in it, it’s done.
> No
> > > > > more tick-tock.
> > > > >
> > > > > I further suggest that in place of tick tock we go back to our old
> > > model of
> > > > > yearly-ish releases with as-needed bug fix releases on stable
> > branches,
> > > > > probably bi-monthly. This amortizes the release validation problem
> > > over a
> > > > > longer development period. And of course we remain free to ramp
> back
> > > up to
> > > > > the more rapid cadence envisioned by the other proposals if we
> > > increase our
> > > > > pool of QA effort or we are able to eliminate flakey tests to the
> > point
> > > > > that a long validation process becomes unnecessary.
> > > > >
> > > > > (While a longer dev period could mean a correspondingly more
> painful
> > > test
> > > > > validation process at the end, my experience is that most of the
> > > validation
> > > > > cost is “fixed” in the form of flaky tests and thus does not
> increase
> > > > > proportionally to development time.)
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > --
> > > > > Jonathan Ellis
> > > > > co-founder, http://www.datastax.com
> > > > > @spyced
> > > > >
> > >
> >
> >
> >
> > --
> > Jonathan Ellis
> > co-founder, http://www.datastax.com
> > @spyced
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message