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