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. > > 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.
