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

Re: Scratch an itch

On Thu, Jul 12, 2018 at 10:54 AM, Michael Burman <miburman@xxxxxxxxxx>

> 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

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