As I said before
> The more significant cost to the project is distracting contributors focused
> on 4.0
This a conversation we keep coming back to, so I will highlight this phrase for
future repetition: Work does not happen in a vacuum. The whole community bears
a cost when new work is integrated.
I am personally not interested in further breaking the backs of those
individuals who have been working to exhaustion for some time to fix historical
issues, so that we can accommodate some mythical organisation that has never
yet contributed, and only won't because they don't care to participate in the
project's goals. If they really do want to get involved, they can either wait
until the project is ready or get involved in shipping 4.0.
On 11/09/2020, 10:53, "Benjamin Lerer" <benjamin.le...@datastax.com> wrote:
>
> People might be itching to get out, particularly those who are unlikely to
> be harmed, but most agree to stay put for the benefit of the community.
>
The freeze has been there for quite a while now and as far as I can see the
goal of all those working on C* right now is to have 4.0 out. Will there
really be a move of resources knowing that the new work will never be
released if 4.0 is not?
On one side we have the fear to delay 4.0 on the other the fear to lose
people who would want to contribute but are not interested in contributing
to testing.
I trust that there are people or companies interested in contributing but
not in testing. Amazon if I recall correctly mentioned that they wanted to
contribute and are probably not so much interested in testing 4.0. I
imagine that it might be the same for some other vendors.
As a developer looking to contribute to an open source project, I would
probably avoid projects that have been frozen for more than a year.
Allowing people with diverse goals to get involved can only help the
project in my opinion. As once you have been involved you will want your
contribution to be released.
As far as I am concerned a new branch will not change my main goal which is
to have 4.0 out of the door.
On Fri, Sep 11, 2020 at 11:03 AM Benedict Elliott Smith
<bened...@apache.org>
wrote:
> This is a social enterprise, and we are all able to enter into a social
> contract/convention. This doesn't prevent someone from breaking the
> convention, or not agreeing to it, of course, but this entails social
> costs. This is exactly how the feature-freeze has worked until now,
> curtailing development - not just merging.
>
> Work conducted without the engagement of the community can also expect to
> be heavily revised when the community finally engages with it, as
signalled
> with the CEP process.
>
> I personally do not condone a total relaxation of the freeze, even to a
> volunteer-maintained repository. We can perhaps think of the freeze like
a
> pandemic lockdown: if we relax before we have the correct measures in
> place, much of the good work will be undone. People might be itching to
> get out, particularly those who are unlikely to be harmed, but most agree
> to stay put for the benefit of the community. However, the community
might
> together agree to a partial-relaxation if it can be done safely.
>
>
>
>
> On 11/09/2020, 04:09, "Jeff Jirsa" <jji...@gmail.com> wrote:
> > On Sep 10, 2020, at 2:42 PM, Benedict Elliott Smith <
> bened...@apache.org> wrote:
> >
> >
> >>
> >> As I understand Sankalp's primary (and quite reasonable) argument
> the last time we discussed this
> >
> > The more significant cost to the project is distracting contributors
> focused on 4.0. The project is bandwidth constrained right now. Feature
> development doesn't happen in a vacuum, and some of that bandwidth will
> have to go to participating in any new feature development. So, if
feature
> development begins in earnest, the 4.0 ship date will slip - by how much,
> who knows?
> >
> > Of course, the new features will also get less attention than they
> should. So it's a lose-lose in that respect.
> >
> > I think if we are to consider this, any ticket or project for 5.0
> should be subject to a consensus vote before work begins. Work that a
> contributor - focused on the more urgent and less rewarding job of
shipping
> 4.0 - would participate in can be deferred. Uncontentious work, or work
> where all relevant contributors are free to participate, can make
progress.
>
> I have no opinion on branching, but I think we all know it’s not
> reasonable to say what people can and can’t work on in any open source
> project. PMC members and committers get an opinion on what goes in the
> repo, but not what gets worked on or reviewed by other committers.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
