osdir.com


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

Re: Testing 4.0 Post-Freeze


I guess I look at the initial voting in of committers as the process
by which people are trusted to merge things in.  This proposed process
revokes that trust. If Jonathan Ellis or Dave Brosius (arbitrarily
picked) wants to merge a new feature into trunk during the freeze, now
they're not allowed?  That's absurd.  People have already met the bar
and have been voted in by merit, they should not have their privilege
revoked.
On Tue, Jul 10, 2018 at 10:14 AM Ben Bromhead <ben@xxxxxxxxxxxxxxx> wrote:
>
> Well put Mick
>
> +1
>
> On Tue, Jul 10, 2018 at 1:06 PM Aleksey Yeshchenko <aleksey@xxxxxxxxx>
> wrote:
>
> > +1 from me too.
> >
> > —
> > AY
> >
> > On 10 July 2018 at 04:17:26, Mick Semb Wever (mck@xxxxxxxxxx) wrote:
> >
> >
> > > We have done all this for previous releases and we know it has not
> > worked
> > > well. So how giving it one more try is going to help here. Can someone
> > > outline what will change for 4.0 which will make it more successful?
> >
> >
> > I (again) agree with you Sankalp :-)
> >
> > Why not try something new?
> > It's easier to discuss these things more genuinely after trying it out.
> >
> > One of the differences in the branching approaches: to feature-freeze on a
> > 4.0 branch or on trunk; is who it is that has to then merge and work with
> > multiple branches.
> >
> > Where that small but additional effort is placed I think becomes a signal
> > to what the community values most: new features or stability.
> >
> > I think most folk would vote for stability, so why not give this approach
> > a go and to learn from it.
> > It also creates an incentive to make the feature-freeze period as short as
> > possible, moving us towards an eventual goal of not needing to
> > feature-freeze at all.
> >
> > regards,
> > Mick
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> > For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
> >
> > --
> Ben Bromhead
> CTO | Instaclustr <https://www.instaclustr.com/>
> +1 650 284 9692
> Reliability at Scale
> Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer



-- 
Jon Haddad
http://www.rustyrazorblade.com
twitter: rustyrazorblade

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx