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
