Re: [VOTE] Branching Change for 4.0 Freeze
> Vote will be open for 72 hours. +1 (non-binding) - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [VOTE] Branching Change for 4.0 Freeze
+1 On 12 July 2018 at 08:49, Mick Semb Wever wrote: > > > Vote will be open for 72 hours. > > > +1 (non-binding) > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: [VOTE] Branching Change for 4.0 Freeze
-0 I'm not interested in sparking a discussion on this, because a) it has already happened and b) it seems I am in a minority. But thought I should at least include the rationale for my vote: * This proposal goes against the "scratch an itch" philosophy of making contributions to an Apache project and IMO will discourage contributions that are casual or new. * It feels dictatorial. IMO the right way to do this would be for impassioned committers to -1 any patch that goes against elements a, b, or c of what this vote is for. Gary. On Wed, Jul 11, 2018 at 4:46 PM sankalp kohli wrote: > Hi, > As discussed in the thread[1], we are proposing that we will not branch > on 1st September but will only allow following merges into trunk. > > a. Bug and Perf fixes to 4.0. > b. Critical bugs in any version of C*. > c. Testing changes to help test 4.0 > > If someone has a change which does not fall under these three, we can > always discuss it and have an exception. > > Vote will be open for 72 hours. > > Thanks, > Sankalp > > [1] > > https://lists.apache.org/thread.html/494c3ced9e83ceeb53fa127e44eec6e2588a01b769896b25867fd59f@%3Cdev.cassandra.apache.org%3E >
Scratch an itch (was: [VOTE] Branching Change for 4.0 Freeze)
These are some valid concerns. But I don’t really see it that way after thinking about it. We already have restrictions and consensus based practices in place that may discourage new contributors. E.g. if someone submits a patch to enable a different GC by default in 2.1, that’s probably not going to happen, even if carefully tested by the contributor. We also don’t accept any patches at all for older 3.x versions, although there may be people who are not able to update to 3.11 and would really like to get their 3.x version patched for something. That’s not because we want to discourage people from contributing in a “scratch an itch” way. It’s just what we agreed on how to coordinate our efforts and what kind of patches to accept for individual releases. So if it’s fine to tell people that we’re not able to accept patches for any version they are already running, why should we not be able to do so for an upcoming, unreleased version that isn’t even used by anyone at this point? Also, if we tell someone that their contribution will be reviewed and committed later after 4.0-beta, how is that actually making a difference for that person, compared to committing it now for a 4.x version. It may be satisfying to get a patch committed, but what matters more is when the code will actually be released and deferring committing contributions after 4.0-beta doesn't necessarily mean that there's any disadvantage when it comes to that. On 12.07.18 15:23, Gary Dusbabek wrote: > -0 > > I'm not interested in sparking a discussion on this, because a) it has > already happened and b) it seems I am in a minority. But thought I should > at least include the rationale for my vote: > * This proposal goes against the "scratch an itch" philosophy of making > contributions to an Apache project and IMO will discourage contributions > that are casual or new. > * It feels dictatorial. IMO the right way to do this would be for > impassioned committers to -1 any patch that goes against elements a, b, or > c of what this vote is for. > > Gary. > > > On Wed, Jul 11, 2018 at 4:46 PM sankalp kohli > wrote: > >> Hi, >> As discussed in the thread[1], we are proposing that we will not branch >> on 1st September but will only allow following merges into trunk. >> >> a. Bug and Perf fixes to 4.0. >> b. Critical bugs in any version of C*. >> c. Testing changes to help test 4.0 >> >> If someone has a change which does not fall under these three, we can >> always discuss it and have an exception. >> >> Vote will be open for 72 hours. >> >> Thanks, >> Sankalp >> >> [1] >> >> https://lists.apache.org/thread.html/494c3ced9e83ceeb53fa127e44eec6e2588a01b769896b25867fd59f@%3Cdev.cassandra.apache.org%3E >> - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [VOTE] Branching Change for 4.0 Freeze
+1 (assuming merging patches on documentation will always be possible, as it's not effecting the code base) On 11.07.18 23:46, sankalp kohli wrote: > Hi, > As discussed in the thread[1], we are proposing that we will not branch > on 1st September but will only allow following merges into trunk. > > a. Bug and Perf fixes to 4.0. > b. Critical bugs in any version of C*. > c. Testing changes to help test 4.0 > > If someone has a change which does not fall under these three, we can > always discuss it and have an exception. > > Vote will be open for 72 hours. > > Thanks, > Sankalp > > [1] > https://lists.apache.org/thread.html/494c3ced9e83ceeb53fa127e44eec6e2588a01b769896b25867fd59f@%3Cdev.cassandra.apache.org%3E > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [VOTE] Branching Change for 4.0 Freeze
merging non code will be allowed correct On Thu, Jul 12, 2018 at 9:41 AM Stefan Podkowinski wrote: > +1 > > (assuming merging patches on documentation will always be possible, as > it's not effecting the code base) > > > On 11.07.18 23:46, sankalp kohli wrote: > > Hi, > > As discussed in the thread[1], we are proposing that we will not > branch > > on 1st September but will only allow following merges into trunk. > > > > a. Bug and Perf fixes to 4.0. > > b. Critical bugs in any version of C*. > > c. Testing changes to help test 4.0 > > > > If someone has a change which does not fall under these three, we can > > always discuss it and have an exception. > > > > Vote will be open for 72 hours. > > > > Thanks, > > Sankalp > > > > [1] > > > https://lists.apache.org/thread.html/494c3ced9e83ceeb53fa127e44eec6e2588a01b769896b25867fd59f@%3Cdev.cassandra.apache.org%3E > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: Scratch an itch
On 07/12/2018 07:38 PM, Stefan Podkowinski wrote: this point? Also, if we tell someone that their contribution will be reviewed and committed later after 4.0-beta, how is that actually making a difference for that person, compared to committing it now for a 4.x version. It may be satisfying to get a patch committed, but what matters more is when the code will actually be released and deferring committing contributions after 4.0-beta doesn't necessarily mean that there's any disadvantage when it comes to that. Deferring huge amount of commits gives rebase/redo hell. That's the biggest impact and the order in which these deferred commits are then actually committed can make it more painful or less painful depending on the commit. And that in turn will have to then wait for each contributor to rebase/redo their commit and those timings might make more rebase issues. If those committers will want to rebase something after n-months or have time at that point. That's a problem for all Cassandra patches that take huge time to commit and if this block takes a lot of time, then that will for sure be even more painful. I know products such as Kubernetes does the same (I guess that's where this idea might have come from) "trunk patches only", but their block is quite short. My wish is that this freeze does not last too long to kill enthusiasm towards committing to Cassandra. There are (I assume) many hobbyist who do this as a side-project instead of their daily work and might not have the capabilities to test 4.0 in a way that will trigger bugs (easy bugs are fixed quite quickly I hope). And if they feel like it's not worth the time at this point to invest time to Cassandra (because nothing they do will get merged) - they might move to another project. And there's no guarantee they will return. Getting stuff to the product is part of the satisfaction and without satisfaction there's no interest in continuing. - Micke - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Scratch an itch
On Thu, Jul 12, 2018 at 10:54 AM, Michael Burman wrote: > On 07/12/2018 07:38 PM, Stefan Podkowinski wrote: > >> this point? Also, if we tell someone that their contribution will be >> reviewed and committed later after 4.0-beta, how is that actually making >> a difference for that person, compared to committing it now for a 4.x >> version. It may be satisfying to get a patch committed, but what matters >> more is when the code will actually be released and deferring committing >> contributions after 4.0-beta doesn't necessarily mean that there's any >> disadvantage when it comes to that. >> >> Deferring huge amount of commits gives rebase/redo hell. That's the > biggest impact and the order in which these deferred commits are then > actually committed can make it more painful or less painful depending on > the commit. And that in turn will have to then wait for each contributor to > rebase/redo their commit and those timings might make more rebase issues. > If those committers will want to rebase something after n-months or have > time at that point. > > This is true, but it's also part of the point - if the people fixing bugs for 4.0 proper have to spend a bunch of time rebasing around 4.next features, then that rebase hell gets in the way of fixing bugs for a release (because we wouldn't commit just to 4.0 without also rebasing for trunk). > That's a problem for all Cassandra patches that take huge time to commit > and if this block takes a lot of time, then that will for sure be even more > painful. I know products such as Kubernetes does the same (I guess that's > where this idea might have come from) "trunk patches only", but their block > is quite short. > > My wish is that this freeze does not last too long to kill enthusiasm > towards committing to Cassandra. There are (I assume) many hobbyist who do > this as a side-project instead of their daily work and might not have the > capabilities to test 4.0 in a way that will trigger bugs (easy bugs are > fixed quite quickly I hope). And if they feel like it's not worth the time > at this point to invest time to Cassandra (because nothing they do will get > merged) - they might move to another project. And there's no guarantee they > will return. Getting stuff to the product is part of the satisfaction and > without satisfaction there's no interest in continuing. > I wish for this too.
Re: Scratch an itch
> > Deferring huge amount of commits gives rebase/redo hell. That's the > biggest impact and the order in which these deferred commits are then > actually committed can make it more painful or less painful depending on > the commit. And that in turn will have to then wait for each contributor > to rebase/redo their commit and those timings might make more rebase > issues. If those committers will want to rebase something after n-months > or have time at that point. This was a concern I had initially as well, but the more I thought about it, the less concerned I became. If trunk drifts far away from a 4.0 branch, we would *still* have to deal with the pain of merging everything forward. It would just change who is responsible for doing the work. On Thu, Jul 12, 2018 at 10:54 AM Michael Burman wrote: > On 07/12/2018 07:38 PM, Stefan Podkowinski wrote: > > this point? Also, if we tell someone that their contribution will be > > reviewed and committed later after 4.0-beta, how is that actually making > > a difference for that person, compared to committing it now for a 4.x > > version. It may be satisfying to get a patch committed, but what matters > > more is when the code will actually be released and deferring committing > > contributions after 4.0-beta doesn't necessarily mean that there's any > > disadvantage when it comes to that. > > > Deferring huge amount of commits gives rebase/redo hell. That's the > biggest impact and the order in which these deferred commits are then > actually committed can make it more painful or less painful depending on > the commit. And that in turn will have to then wait for each contributor > to rebase/redo their commit and those timings might make more rebase > issues. If those committers will want to rebase something after n-months > or have time at that point. > > That's a problem for all Cassandra patches that take huge time to commit > and if this block takes a lot of time, then that will for sure be even > more painful. I know products such as Kubernetes does the same (I guess > that's where this idea might have come from) "trunk patches only", but > their block is quite short. > > My wish is that this freeze does not last too long to kill enthusiasm > towards committing to Cassandra. There are (I assume) many hobbyist who > do this as a side-project instead of their daily work and might not have > the capabilities to test 4.0 in a way that will trigger bugs (easy bugs > are fixed quite quickly I hope). And if they feel like it's not worth > the time at this point to invest time to Cassandra (because nothing they > do will get merged) - they might move to another project. And there's no > guarantee they will return. Getting stuff to the product is part of the > satisfaction and without satisfaction there's no interest in continuing. > >- Micke > > - > 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
Re: [VOTE] Branching Change for 4.0 Freeze
-0. Agree w/Gary, but not willing to die on this hill. We'll see how it goes. On Thu, Jul 12, 2018 at 12:46 PM sankalp kohli wrote: > merging non code will be allowed correct > > On Thu, Jul 12, 2018 at 9:41 AM Stefan Podkowinski > wrote: > > > +1 > > > > (assuming merging patches on documentation will always be possible, as > > it's not effecting the code base) > > > > > > On 11.07.18 23:46, sankalp kohli wrote: > > > Hi, > > > As discussed in the thread[1], we are proposing that we will not > > branch > > > on 1st September but will only allow following merges into trunk. > > > > > > a. Bug and Perf fixes to 4.0. > > > b. Critical bugs in any version of C*. > > > c. Testing changes to help test 4.0 > > > > > > If someone has a change which does not fall under these three, we can > > > always discuss it and have an exception. > > > > > > Vote will be open for 72 hours. > > > > > > Thanks, > > > Sankalp > > > > > > [1] > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.apache.org_thread.html_494c3ced9e83ceeb53fa127e44eec6e2588a01b769896b25867fd59f-40-253Cdev.cassandra.apache.org-253E&d=DwIBaQ&c=adz96Xi0w1RHqtPMowiL2g&r=qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4&m=GS86ylUneBUP3PqeIQnmNEAfdoZqEcRktyqJTCQGG-M&s=RhWFmvP4otwY6nCR2hIiOAvOEVJ6Rekp5-R-ykw1wKI&e= > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > >
