git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Testing 4.0 Post-Freeze


>
> We propose that between the September freeze date and beta, a new branch
> would not be created and trunk would only have bug fixes and performance
> improvements committed to it.


This is more of a call to action and announcement of intent than an attempt
> to
> enforce policy; we can and probably will branch off 4.0, and keep trunk
> technically active.

These are two very different statements. :) Which is it?

On Tue, Jul 3, 2018 at 5:57 PM Aleksey Yeshchenko <aleksey@xxxxxxxxx> wrote:

> If we want to have a stable, usable 4.0.0 release out in the next 6-12
> months, there needs to be a focused effort on getting it out - or else
> it’ll just never happen.
>
> This is more of a call to action and announcement of intent than an
> attempt to enforce policy; we can and probably will branch off 4.0, and
> keep trunk technically active. But so long as there is a critical mass of
> active contributors who are on board with only/mostly working on stability,
> bug fixes, and validation - both as assignees and reviewers - we’ll have a
> de-facto freeze.
>
> And I have a feeling that there is such a critical mass.
>
> —
> AY
>
> On 3 July 2018 at 22:23:38, Jeff Jirsa (jjirsa@xxxxxxxxx) wrote:
>
> I think there's value in the psychological commitment that if someone has
> time to contribute, their contributions should be focused on validating a
> release, not pushing future features.
>
>
> On Tue, Jul 3, 2018 at 1:03 PM, Jonathan Haddad <jon@xxxxxxxxxxxxx>
> wrote:
>
> > I agree with Josh. I don’t see how changing the convention around trunk
> > will improve the process, seems like it’ll only introduce a handful of
> > rollback commits when people forget.
> >
> > Other than that, it all makes sense to me.
> >
> > I’ve been working on a workload centric stress tool on and off for a
> little
> > bit in an effort to create something that will help with wider adoption
> in
> > stress testing. It differs from the stress we ship by including fully
> > functional stress workloads as well as a validation process. The idea
> being
> > to be flexible enough to test both performance and correctness in LWT
> and
> > MVs as well as other arbitrary workloads.
> >
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_thelastpickle_tlp-2Dstress&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4&m=l_G2ByhfCyu3k9TzNVqiagdVQ8vOMJqHZvDq_JKvbiQ&s=f8gf_JCP6JRQIRkL_1R_zJOS_6gdAAsLleDr2PZHppE&e=
>
> >
> > Jon
> >
> >
> > On Tue, Jul 3, 2018 at 12:28 PM Josh McKenzie <jmckenzie@xxxxxxxxxx>
> > wrote:
> >
> > > Why not just branch a 4.0-rel and bugfix there and merge up while
> still
> > > accepting new features or improvements on trunk?
> > >
> > > I don't think the potential extra engagement in testing will balance
> out
> > > the atrophy and discouraging contributions / community engagement
> we'd
> > get
> > > by deferring all improvements and new features in an open-ended way.
> > >
> > > On Tue, Jul 3, 2018 at 1:33 PM sankalp kohli <kohlisankalp@xxxxxxxxx>
>
> > > wrote:
> > >
> > > > Hi cassandra-dev@,
> > > >
> > > > With the goal of making Cassandra's 4.0 the most stable major
> release
> > to
> > > > date, we would like all committers of the project to consider
> joining
> > us
> > > in
> > > > dedicating their time and attention to testing, running, and fixing
> > > issues
> > > > in 4.0 between the September freeze and the 4.0 beta release. This
> > would
> > > > result in a freeze of new feature development on trunk or branches
> > during
> > > > this period, instead focusing on writing, improving, and running
> tests
> > or
> > > > fixing and reviewing bugs or performance regressions found in 4.0
> or
> > > > earlier.
> > > >
> > > > How would this work?
> > > >
> > > > We propose that between the September freeze date and beta, a new
> > branch
> > > > would not be created and trunk would only have bug fixes and
> > performance
> > > > improvements committed to it. At the same time we do not want to
> > > discourage
> > > > community contributions. Not all contributors can be expected to be
> > aware
> > > > of such a decision or may be new to the project. In cases where new
> > > > features are contributed during this time, the contributor can be
> > > informed
> > > > of the current status of the release process, be encouraged to
> > contribute
> > > > to testing or bug fixing, and have their feature reviewed after the
> > beta
> > > is
> > > > reached.
> > > >
> > > >
> > > > What happens when beta is reached?
> > > >
> > > > Ideally, contributors who have made significant contributions to
> the
> > > > release will stick around to continue testing between beta and
> final
> > > > release. Any additional folks who continue this focus would also be
> > > greatly
> > > > appreciated.
> > > >
> > > > What about before the freeze?
> > > >
> > > > Testing new features is of course important. This isn't meant to
> > > discourage
> > > > development – only to enable us to focus on testing and hardening
> 4.0
> > to
> > > > deliver Cassandra's most stable major release. We would like to see
> > > > adoption of 4.0 happen much more quickly than its predecessor.
> > > >
> > > > Thanks for considering this proposal,
> > > > Sankalp Kohli
> > >
> > --
> > Jon Haddad
> >
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.rustyrazorblade.com&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4&m=l_G2ByhfCyu3k9TzNVqiagdVQ8vOMJqHZvDq_JKvbiQ&s=paSngQpMm3DhoWay8lDuWEYELVOrti8evQeT1LodXdY&e=
>
> > twitter: rustyrazorblade
> >