You're right - if we do decide we're wrong we can always create the branch later.
I retract my -1. On Tue, Jul 10, 2018 at 10:50 AM Benedict Elliott Smith <bened...@apache.org> wrote: > > 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 > -- 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
