That’s a peculiar way of looking at it. Committer status is not an absolute right to autonomy over the codebase. It’s an embodiment of trust that you will follow the community's prevailing rules around commit, and that you’re competent to do so.
If the community wants to change those rules you’re trusted to follow, how does this modify your right, or the trust emplaced in you? > On 10 Jul 2018, at 10:18, 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
