git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 <miburman@xxxxxxxxxx> 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-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
>
>

-- 
Jon Haddad
http://www.rustyrazorblade.com
twitter: rustyrazorblade