Hi,
I hear the following
"Freeze is causing contributions to go away and stopping innovation"
"Lack of 4.0 release is causing people to think C* is dead."
I think it is important to think why we are here. We are here as we shipped
3.0 with 10s of correctness bug. So the statements should be
"3.0 shipped with 10s of correctness bugs and that is causing contributions
to go away and stopping innovation"
"Lack of 4.0 release due to 3.0 shipping with 10s of correctness bugs is
causing people to think C* is dead."
Once we start putting it this way, we can start debating on how not to make
4.0 like 3.0 and cause 5.0 to be delayed. So instead of focusing on
symptoms and major effects 3.0 + correctness bugs has caused, lets talk
about following
1. How can we make 4.0 stable so we dont have to freeze for 2+ years and
dont ship with 10s of correctness bugs.
2. How can we have a stable .0 release instead of people not using it for
10th minor.
3. How can we have a predictable timeline for major releases like 4.0 so
contributors/users knows how to plan around it.
I think it is more important to fix the root cause than fixing the
symptoms.
Thanks,
Sankalp
On Thu, Sep 24, 2020 at 10:50 AM Brandon Williams <dri...@gmail.com> wrote:
> On Thu, Sep 24, 2020 at 12:22 PM sankalp kohli <kohlisank...@gmail.com>
> wrote:
> >
> > Hi Brandon,
> > In all respect, we need to discuss and vote before we
> > create a new branch. So it is best if we do that instead of creating
> > branches.
>
> Fair enough.
>
> > Freeze is a symptom not a cause so if we dont like the symptom,
> > we should see how to fix the cause. Are we fine having a database release
> > which will be released with 10s of correctness bugs and with an implicit
> > assumption that no one will use it in prod till 10th minor.
>
> I think we're making quite a leap to go from adding new features in
> one branch equating to releasing software with more bugs in a
> completely different branch. I think your concern is that by having
> the project 'bless' a feature-accepting branch, this will detract from
> time they would otherwise spend on stabilizing the release branch (if
> we had one.) I can't fault you for this, it may be a real
> possibility, nobody knows. Nothing can be done about changing what
> people decide to work on in a free project, however, and it would be
> naive to think there are not people already out there interested in
> working purely on new features, with no dog in the stability of 4.0
> fight. I know that's not conducive to your goals (and honestly I'd
> rather they help on the 4.0 side too) but that's just the way things
> are.
>
> > Everyone wants to innovate but security, durability and availability
> comes
> > first. People who are working on stabilizing 4.0 are doing it as there
> is
> > no other choice. So I request you to kindly cooperate on working with
> them
> > in making 4.0 a stable release.
>
> Sorry, but I respectfully refuse your statement that there is no other
> choice. This is a free project and there is always a choice for those
> who may wish to donate their time. I would like to cast a wide enough
> net to allow all their itches to be scratched here for the future
> health of this project.
>
> Kind Regards,
> Brandon
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>
