Ultimately, we have a consensus driven development. If Jonathan or Dave strongly disagrees with this, they can share their strong disagreement.
Jonathan shared his concern about dissuading contributors. What's absurd is trying the same thing we've tried for 10 years and expecting things to magically change. We know that a lot of folks are lining up to test the 4.0 release. If people who have contributed enough to be able to commit have time to work on features, the proposal is that the project make it known that we'd rather have them work on testing than commit their patch, or hold their patch until testing is done. That doesn't mean they're suddenly not allowed to commit, it's that we'd prefer they use their time and attention in a more constructive manner. - Jeff On Tue, Jul 10, 2018 at 10:18 AM, Jonathan Haddad <j...@jonhaddad.com> wrote: > 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 <b...@instaclustr.com> wrote: > > > > Well put Mick > > > > +1 > > > > On Tue, Jul 10, 2018 at 1:06 PM Aleksey Yeshchenko <alek...@apple.com> > > wrote: > > > > > +1 from me too. > > > > > > — > > > AY > > > > > > On 10 July 2018 at 04:17:26, Mick Semb Wever (m...@apache.org) 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-unsubscr...@cassandra.apache.org > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > -- > > 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-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
