If this motivates individuals and organizations to contribute time and resources to testing more before the release then +1. The varied testing before the release will make a huge difference.
> On Jul 10, 2018, at 12:30 PM, Jeff Jirsa <jji...@gmail.com> wrote: > > 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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
