I guess I look at the idea of changing the branching strategy as a means of blocking work as a very odd way of solving a human problem. Having a majority of votes temporarily block potentially good work might be a good thing, and it might not matter at all. It might also frustrate some folks who have been around for a really long time.
I'm also making the assumption that I don't know every plausible reason someone might need / want to merge into trunk and considering that there's valid cases for it that we'll be blocking. With regard to "the process has been broken for years" I've already said my bit on what I considered to different now, nobody has responded to that yet. I think I've said all I need to on this, it's probably just noise now, so I won't respond any further on this thread. I don't anticipate having a personal need to commit to a future 5.0 release before 4.0 is out, so it won't impact me personally. On Tue, Jul 10, 2018 at 10:32 AM Benedict Elliott Smith <bened...@apache.org> wrote: > > 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 > -- 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
