It’s not like this is an irrevocable change. If we encounter a scenario that seems to question its validity, or its general applicability, it can be raised on the mailing list and we can revisit the decision, surely? I can think of at least one way to weaken the rules in such a scenario, without frustrating the goal, but why complicate things when we can’t even yet imagine a situation to need it - besides discouraging a new contributor who, let’s be honest, was going to have their patch languish for a few months while somebody found time to review it anyway. At least this way we can give them a decent excuse!
> On 10 Jul 2018, at 10:43, Jonathan Haddad <j...@jonhaddad.com> wrote: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
