git.net

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

Re: Testing 4.0 Post-Freeze


I did not see a -1 but all +0s and a few +1s.

On Mon, Jul 9, 2018 at 5:49 AM Josh McKenzie <jmckenzie@xxxxxxxxxx> wrote:

> What did we land on? Sounds like we're pretty split without consensus on
> "change the old branching strategy and reject new things on trunk during
> stabilization" vs. "keep doing things the way we did but message strongly
> that we won't be reviewing new things until 4.0 is stable".
>
> On Sat, Jul 7, 2018 at 5:01 PM Sankalp Kohli <kohlisankalp@xxxxxxxxx>
> wrote:
>
> > Does anyone has any more feedback on this?
> >
> > > On Jul 4, 2018, at 05:36, Aleksey Yeshchenko <aleksey@xxxxxxxxx>
> wrote:
> > >
> > > For what it’s worth, I’m fine with both formal branching-level freeze
> > and informal ‘let people commit to trunk if they can find a reviewer’ one
> > and will support either.
> > >
> > > So long as either/both are communicated to the contributors, the only
> > difference is in where new feature work gets accumulated: will stay a bit
> > longer in personal branches in the latter way.
> > >
> > > —
> > > AY
> > >
> > > On 4 July 2018 at 01:30:40, sankalp kohli (kohlisankalp@xxxxxxxxx)
> > wrote:
> > >
> > > Having an explicit way to tell the community that we all will work on
> > > testing is better than writing a patch which will sit without review
> > for
> > > months. I think not having your patch reviewed for months is more
> > > discouraging than following the community and helping with stability of
> > > 4.0.
> > >
> > >
> > >
> > > On Tue, Jul 3, 2018 at 3:02 PM Josh McKenzie <jmckenzie@xxxxxxxxxx>
> > wrote:
> > >
> > >>>
> > >>> 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
> > >>>>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> > For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
>