> > 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 <mibur...@redhat.com> 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
