Re: Creating a branch for 5.0 …?
several things to improve the 4.0 process including that "we lack clarity around scoping of this release and don't seem to have a project-wide consensus on how we're handling this." Gotcha. Yeah, for me the argument of "people working on 4.0 should have to carry the burden of merging forward" is a completely unarguable reality in the "branch 4.0" model. Having a cassandra-5.0 branch alleviates that dynamic. I definitely agree re: the benefit of project-wide engagement on defining what is in and out of scope for 4.0 GA, as well as getting back in the saddle of weekly or biweekly updates on the status. Our creation vs. close has inverted again w/the focus on 40_quality_test tickets and I'm not sure people are aware of that, and whether or not they'd change their behavior or engagement on the project based on that. More an optics / vanity thing than anything though since it's mostly about discovering scope. I think we'd do better to improve the situation in this regard and have a plan to get 4.0 out instead of debating branching. An official 5.0 branch is only as useful as the 5.0 release timeline I disagree on the limitations of its usefulness. A reality we in open source face is that nowadays, a lot of people working on open source projects are sponsored by corporate entities with different priorities or just have different priorities themselves as volunteers. Sometimes those priorities align with each other, sometimes they don't. The more voices and contributions we can encourage, the better for the project's long term health. That's my belief. It's very possible others on this thread believe that discouraging contribution from some sources is preferable for the health of the project. That seems like it could be healthy to talk about openly if so. Forcing people with different priorities to do their work outside the project encourages forking. There's at least 5 majors that I know of atm, including ironically *for almost all of us participating on this thread*. There's an alternate timeline in which all of us would be collaborating on one project right now; I personally prefer that one and would like to see us get as close to that as possible. On Fri, Sep 11, 2020 at 12:32 PM, Jordan West wrote: > On Fri, Sep 11, 2020 at 9:18 AM Joshua McKenzie > wrote: > > I thought it was the former; seems like it's > the latter. > > Looking at the thread I link, both are discussed (initially the former but > it turns to the latter briefly as well before going down a path similar to > the one this thread is starting to go down). In that thread we discuss > several things to improve the 4.0 process including that "we lack clarity > around scoping of this release and don't seem to have a project-wide > consensus on how we're handling this.". I think we'd do better to improve > the situation in this regard and have a plan to get 4.0 out instead of > debating branching. An official 5.0 branch is only as useful as the 5.0 > release timeline (otherwise its just a branch name, maintenance, and > unreleased code). Thats predicated on us getting 4.0 out the door anyways. > > Jordan > > On Fri, Sep 11, 2020 at 12:10 PM, Jordan West wrote: > > It still seems to me that the best use of our efforts as a community is > > to > > come together to get a stable 4.0 out as fast as possible. It would > > address > > the branching and freeze issues that have been raised -- neither of which > currently prevent people from "scratching an itch", maintaining a > non-official side branch, or running CI on those branches. We've > > generally > > stopped on the "planning" (I use this word lightly) or progress checking > front since beta was released. > > Also, fwiw, it seems unlikely this conversation will be any different > > than > > the one we had on the same topic 11 weeks ago: > https://lists.apache.org/thread.html/ > raf3592f2297abfb120563d216eeea26bfb3a6e048b246492815954ff%40%3Cdev. > cassandra.apache.org%3E > . > > Jordan > > On Fri, Sep 11, 2020 at 5:44 AM Benedict Elliott Smith org> wrote: > > if we do these contributions in secret > > Are you aware of any work happening (or expected to happen) in this way? > This seems a very different problem than the one the thread was opened > with. > > it will be even harder for folk to put in late reviews > > It is always harder to revert and revisit committed work, than to review > work that has not been merged. So the flood gates you expect to open will > still flood those people working on 4.0, only worse. There is also no > > such > > thing as a "late review" in this context; the review happens, at whatever > pace is necessary, as agreed recently by the community. If an > > organisation > > drops several huge patches, progress will quite reasonably be slow. The > best way to mitigate this would be to invest more of those secret > > resources > > into shipping 4.0, so the project can be on an even keel. > > On 11/09/2020, 13:06, "Mick Semb Wever" wrote: > > For significant new
Re: Creating a branch for 5.0 …?
On Fri, Sep 11, 2020 at 9:18 AM Joshua McKenzie wrote: > I thought it was the former; seems like it's > the latter. > > Looking at the thread I link, both are discussed (initially the former but it turns to the latter briefly as well before going down a path similar to the one this thread is starting to go down). In that thread we discuss several things to improve the 4.0 process including that "we lack clarity around scoping of this release and don't seem to have a project-wide consensus on how we're handling this.". I think we'd do better to improve the situation in this regard and have a plan to get 4.0 out instead of debating branching. An official 5.0 branch is only as useful as the 5.0 release timeline (otherwise its just a branch name, maintenance, and unreleased code). Thats predicated on us getting 4.0 out the door anyways. Jordan > > > On Fri, Sep 11, 2020 at 12:10 PM, Jordan West wrote: > > > It still seems to me that the best use of our efforts as a community is > to > > come together to get a stable 4.0 out as fast as possible. It would > address > > the branching and freeze issues that have been raised -- neither of which > > currently prevent people from "scratching an itch", maintaining a > > non-official side branch, or running CI on those branches. We've > generally > > stopped on the "planning" (I use this word lightly) or progress checking > > front since beta was released. > > > > Also, fwiw, it seems unlikely this conversation will be any different > than > > the one we had on the same topic 11 weeks ago: > > https://lists.apache.org/thread.html/ > > raf3592f2297abfb120563d216eeea26bfb3a6e048b246492815954ff%40%3Cdev. > > cassandra.apache.org%3E > > . > > > > Jordan > > > > On Fri, Sep 11, 2020 at 5:44 AM Benedict Elliott Smith > org> wrote: > > > > if we do these contributions in secret > > > > Are you aware of any work happening (or expected to happen) in this way? > > This seems a very different problem than the one the thread was opened > > with. > > > > it will be even harder for folk to put in late reviews > > > > It is always harder to revert and revisit committed work, than to review > > work that has not been merged. So the flood gates you expect to open will > > still flood those people working on 4.0, only worse. There is also no > such > > thing as a "late review" in this context; the review happens, at whatever > > pace is necessary, as agreed recently by the community. If an > organisation > > drops several huge patches, progress will quite reasonably be slow. The > > best way to mitigate this would be to invest more of those secret > resources > > into shipping 4.0, so the project can be on an even keel. > > > > On 11/09/2020, 13:06, "Mick Semb Wever" wrote: > > > > For significant new feature work, the option of working in a public, > > > > long-running, trunk-based feature branch is available. If we look at > > > > a > > > > specific example like CEP-7/SAI, I’m not sure how it would benefit > > > > much > > > > from a 5.0 branch, at least until it fundamentally depended on other > > 5.0-targeted work. > > > > Caleb, I'm seeing an important value to the branch (given there's no > > inter-dependencies between patches) is the CI builds on the cassandra-5.0 > > branch, and the efforts of rebasing centralised from many feature > branches > > to one preview branch. > > > > Raising the CEP process is interesting. Anything significant enough to > > warrant a CEP still has to go through that process (which has limited > > throughput atm) and I can't imagine anything that size making it to the > > cassandra-5.0 before we got to 4.0-rc (which is hopefully in a few > months). > > But we are sending the clear signal that we are no longer shutting out > > these contributions. > > > > Maybe the effort should be done in the area of getting more people on > > > > board technically so they can start to review things themselves > > > > (which > > > > indeed takes a lot of time and patience) instead of creating a new branch > > so they can pile up their stuff there. > > > > Stefan, the cassandra-5.0 is not a substitute for reviews. Good habits in > > preparation for reviews: like rebasing your feature branch, having CI > > results ready to view; and the review process itself remains exactly the > > same, and will take the same time as before. > > > > You do have strong review preparation habits in place. I can see that the > > CI builds (not just a selection of tests but the whole complete pipeline) > > being part of the value you are taking advantage of here. We want to > > re-apply that value also to the cassandra-5.0 branch with its patches > that > > are post-review yet, not yet merged to trunk. That CI would help smoke > out > > the combination (sequence) of reviewed patches all put together, and > > easing > > the burden of the re-review of those patches, before they land in trunk. > > > > Again… if the feature freeze is now a quickly shortening window, it's > > going > >
Re: Creating a branch for 5.0 …?
it seems unlikely this conversation will be any different than the one we had on the same topic 11 weeks ago The big difference to me is whether the turning point on the conversation is the extra work required by people working on 4.0 to merge up to a new trunk or if the turning point is on a desire to enforce a certain focus of work on project contributions. I thought it was the former; seems like it's the latter. On Fri, Sep 11, 2020 at 12:10 PM, Jordan West wrote: > It still seems to me that the best use of our efforts as a community is to > come together to get a stable 4.0 out as fast as possible. It would address > the branching and freeze issues that have been raised -- neither of which > currently prevent people from "scratching an itch", maintaining a > non-official side branch, or running CI on those branches. We've generally > stopped on the "planning" (I use this word lightly) or progress checking > front since beta was released. > > Also, fwiw, it seems unlikely this conversation will be any different than > the one we had on the same topic 11 weeks ago: > https://lists.apache.org/thread.html/ > raf3592f2297abfb120563d216eeea26bfb3a6e048b246492815954ff%40%3Cdev. > cassandra.apache.org%3E > . > > Jordan > > On Fri, Sep 11, 2020 at 5:44 AM Benedict Elliott Smith org> wrote: > > if we do these contributions in secret > > Are you aware of any work happening (or expected to happen) in this way? > This seems a very different problem than the one the thread was opened > with. > > it will be even harder for folk to put in late reviews > > It is always harder to revert and revisit committed work, than to review > work that has not been merged. So the flood gates you expect to open will > still flood those people working on 4.0, only worse. There is also no such > thing as a "late review" in this context; the review happens, at whatever > pace is necessary, as agreed recently by the community. If an organisation > drops several huge patches, progress will quite reasonably be slow. The > best way to mitigate this would be to invest more of those secret resources > into shipping 4.0, so the project can be on an even keel. > > On 11/09/2020, 13:06, "Mick Semb Wever" wrote: > > For significant new feature work, the option of working in a public, > > long-running, trunk-based feature branch is available. If we look at > > a > > specific example like CEP-7/SAI, I’m not sure how it would benefit > > much > > from a 5.0 branch, at least until it fundamentally depended on other > 5.0-targeted work. > > Caleb, I'm seeing an important value to the branch (given there's no > inter-dependencies between patches) is the CI builds on the cassandra-5.0 > branch, and the efforts of rebasing centralised from many feature branches > to one preview branch. > > Raising the CEP process is interesting. Anything significant enough to > warrant a CEP still has to go through that process (which has limited > throughput atm) and I can't imagine anything that size making it to the > cassandra-5.0 before we got to 4.0-rc (which is hopefully in a few months). > But we are sending the clear signal that we are no longer shutting out > these contributions. > > Maybe the effort should be done in the area of getting more people on > > board technically so they can start to review things themselves > > (which > > indeed takes a lot of time and patience) instead of creating a new branch > so they can pile up their stuff there. > > Stefan, the cassandra-5.0 is not a substitute for reviews. Good habits in > preparation for reviews: like rebasing your feature branch, having CI > results ready to view; and the review process itself remains exactly the > same, and will take the same time as before. > > You do have strong review preparation habits in place. I can see that the > CI builds (not just a selection of tests but the whole complete pipeline) > being part of the value you are taking advantage of here. We want to > re-apply that value also to the cassandra-5.0 branch with its patches that > are post-review yet, not yet merged to trunk. That CI would help smoke out > the combination (sequence) of reviewed patches all put together, and > easing > the burden of the re-review of those patches, before they land in trunk. > > Again… if the feature freeze is now a quickly shortening window, it's > going > to be very limited to what might make it into such a branch, so mostly > about sending the signal that this final hurdle can be worked around if it > means we retain any such significant new contributions. > > 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. > > Benedict, good point and it loops into what Caleb touches on. The CEP > intends to bring out community involvement earlier in the development > cycle, to avoid the late revisions. And under the feature freeze the CEP > process is an obvious
Re: Creating a branch for 5.0 …?
It still seems to me that the best use of our efforts as a community is to come together to get a stable 4.0 out as fast as possible. It would address the branching and freeze issues that have been raised -- neither of which currently prevent people from "scratching an itch", maintaining a non-official side branch, or running CI on those branches. We've generally stopped on the "planning" (I use this word lightly) or progress checking front since beta was released. Also, fwiw, it seems unlikely this conversation will be any different than the one we had on the same topic 11 weeks ago: https://lists.apache.org/thread.html/raf3592f2297abfb120563d216eeea26bfb3a6e048b246492815954ff%40%3Cdev.cassandra.apache.org%3E . Jordan On Fri, Sep 11, 2020 at 5:44 AM Benedict Elliott Smith wrote: > > if we do these contributions in secret > > Are you aware of any work happening (or expected to happen) in this way? > This seems a very different problem than the one the thread was opened with. > > > it will be even harder for folk to put in late reviews > > It is always harder to revert and revisit committed work, than to review > work that has not been merged. So the flood gates you expect to open will > still flood those people working on 4.0, only worse. There is also no such > thing as a "late review" in this context; the review happens, at whatever > pace is necessary, as agreed recently by the community. If an organisation > drops several huge patches, progress will quite reasonably be slow. The > best way to mitigate this would be to invest more of those secret resources > into shipping 4.0, so the project can be on an even keel. > > > > On 11/09/2020, 13:06, "Mick Semb Wever" wrote: > > For significant new feature work, the option of working in a public, > > long-running, trunk-based feature branch is available. If we look at > a > > specific example like CEP-7/SAI, I’m not sure how it would benefit > much > > from a 5.0 branch, at least until it fundamentally depended on other > > 5.0-targeted work. > > > > > Caleb, I'm seeing an important value to the branch (given there's no > inter-dependencies between patches) is the CI builds on the > cassandra-5.0 > branch, and the efforts of rebasing centralised from many feature > branches > to one preview branch. > > Raising the CEP process is interesting. Anything significant enough to > warrant a CEP still has to go through that process (which has limited > throughput atm) and I can't imagine anything that size making it to the > cassandra-5.0 before we got to 4.0-rc (which is hopefully in a few > months). > But we are sending the clear signal that we are no longer shutting out > these contributions. > > > Maybe the effort should be done in the area of getting more people on > > board technically so they can start to review things themselves > (which > > indeed takes a lot of time and patience) instead of creating a new > > branch so they can pile up their stuff there. > > > > Stefan, the cassandra-5.0 is not a substitute for reviews. Good habits > in > preparation for reviews: like rebasing your feature branch, having CI > results ready to view; and the review process itself remains exactly > the > same, and will take the same time as before. > > You do have strong review preparation habits in place. I can see that > the > CI builds (not just a selection of tests but the whole complete > pipeline) > being part of the value you are taking advantage of here. We want to > re-apply that value also to the cassandra-5.0 branch with its patches > that > are post-review yet, not yet merged to trunk. That CI would help smoke > out > the combination (sequence) of reviewed patches all put together, and > easing > the burden of the re-review of those patches, before they land in > trunk. > > Again… if the feature freeze is now a quickly shortening window, it's > going > to be very limited to what might make it into such a branch, so mostly > about sending the signal that this final hurdle can be worked around > if it > means we retain any such significant new contributions. > > > 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. > > > > Benedict, good point and it loops into what Caleb touches on. The CEP > intends to bring out community involvement earlier in the development > cycle, to avoid the late revisions. And under the feature freeze the > CEP > process is an obvious bottleneck and I don't think we can get around > that. > > As far as dev involvement goes, it doesn't stop just because something > is > merged to trunk, commits in trunk can also be re-reviewed and then > reverted, but that's something we want to avoid. So yes, ofc there > will be >
Re: Creating a branch for 5.0 …?
> if we do these contributions in secret Are you aware of any work happening (or expected to happen) in this way? This seems a very different problem than the one the thread was opened with. > it will be even harder for folk to put in late reviews It is always harder to revert and revisit committed work, than to review work that has not been merged. So the flood gates you expect to open will still flood those people working on 4.0, only worse. There is also no such thing as a "late review" in this context; the review happens, at whatever pace is necessary, as agreed recently by the community. If an organisation drops several huge patches, progress will quite reasonably be slow. The best way to mitigate this would be to invest more of those secret resources into shipping 4.0, so the project can be on an even keel. On 11/09/2020, 13:06, "Mick Semb Wever" wrote: For significant new feature work, the option of working in a public, > long-running, trunk-based feature branch is available. If we look at a > specific example like CEP-7/SAI, I’m not sure how it would benefit much > from a 5.0 branch, at least until it fundamentally depended on other > 5.0-targeted work. > Caleb, I'm seeing an important value to the branch (given there's no inter-dependencies between patches) is the CI builds on the cassandra-5.0 branch, and the efforts of rebasing centralised from many feature branches to one preview branch. Raising the CEP process is interesting. Anything significant enough to warrant a CEP still has to go through that process (which has limited throughput atm) and I can't imagine anything that size making it to the cassandra-5.0 before we got to 4.0-rc (which is hopefully in a few months). But we are sending the clear signal that we are no longer shutting out these contributions. Maybe the effort should be done in the area of getting more people on > board technically so they can start to review things themselves (which > indeed takes a lot of time and patience) instead of creating a new > branch so they can pile up their stuff there. Stefan, the cassandra-5.0 is not a substitute for reviews. Good habits in preparation for reviews: like rebasing your feature branch, having CI results ready to view; and the review process itself remains exactly the same, and will take the same time as before. You do have strong review preparation habits in place. I can see that the CI builds (not just a selection of tests but the whole complete pipeline) being part of the value you are taking advantage of here. We want to re-apply that value also to the cassandra-5.0 branch with its patches that are post-review yet, not yet merged to trunk. That CI would help smoke out the combination (sequence) of reviewed patches all put together, and easing the burden of the re-review of those patches, before they land in trunk. Again… if the feature freeze is now a quickly shortening window, it's going to be very limited to what might make it into such a branch, so mostly about sending the signal that this final hurdle can be worked around if it means we retain any such significant new contributions. 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. Benedict, good point and it loops into what Caleb touches on. The CEP intends to bring out community involvement earlier in the development cycle, to avoid the late revisions. And under the feature freeze the CEP process is an obvious bottleneck and I don't think we can get around that. As far as dev involvement goes, it doesn't stop just because something is merged to trunk, commits in trunk can also be re-reviewed and then reverted, but that's something we want to avoid. So yes, ofc there will be those that want to have their say on things sitting in the 5.0 branch that have otherwise met reviewer requirements, at the same time (as long as the branch remains limited in its scope) this does lengthen out the dev cycle for these contributions providing more patience and soak time for all. I would expect that the maintainers of the branch extend the opportunity for late reviewing to those that were doing The Right Thing focusing all their time on getting 4.0 out, before those commits go into trunk. Opposed to this, if we do these contributions in secret to avoid these types of discussions, only raising them once the feature-freeze is lifted, there may be a flood-gates rush and it will be even harder for folk to put in late reviews. I would certainly rather see exceptions made and things done in public (even if in a fork), though the main concern we are hearing is folk simply walking away altogether. I
Re: Creating a branch for 5.0 …?
For significant new feature work, the option of working in a public, > long-running, trunk-based feature branch is available. If we look at a > specific example like CEP-7/SAI, I’m not sure how it would benefit much > from a 5.0 branch, at least until it fundamentally depended on other > 5.0-targeted work. > Caleb, I'm seeing an important value to the branch (given there's no inter-dependencies between patches) is the CI builds on the cassandra-5.0 branch, and the efforts of rebasing centralised from many feature branches to one preview branch. Raising the CEP process is interesting. Anything significant enough to warrant a CEP still has to go through that process (which has limited throughput atm) and I can't imagine anything that size making it to the cassandra-5.0 before we got to 4.0-rc (which is hopefully in a few months). But we are sending the clear signal that we are no longer shutting out these contributions. Maybe the effort should be done in the area of getting more people on > board technically so they can start to review things themselves (which > indeed takes a lot of time and patience) instead of creating a new > branch so they can pile up their stuff there. Stefan, the cassandra-5.0 is not a substitute for reviews. Good habits in preparation for reviews: like rebasing your feature branch, having CI results ready to view; and the review process itself remains exactly the same, and will take the same time as before. You do have strong review preparation habits in place. I can see that the CI builds (not just a selection of tests but the whole complete pipeline) being part of the value you are taking advantage of here. We want to re-apply that value also to the cassandra-5.0 branch with its patches that are post-review yet, not yet merged to trunk. That CI would help smoke out the combination (sequence) of reviewed patches all put together, and easing the burden of the re-review of those patches, before they land in trunk. Again… if the feature freeze is now a quickly shortening window, it's going to be very limited to what might make it into such a branch, so mostly about sending the signal that this final hurdle can be worked around if it means we retain any such significant new contributions. 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. Benedict, good point and it loops into what Caleb touches on. The CEP intends to bring out community involvement earlier in the development cycle, to avoid the late revisions. And under the feature freeze the CEP process is an obvious bottleneck and I don't think we can get around that. As far as dev involvement goes, it doesn't stop just because something is merged to trunk, commits in trunk can also be re-reviewed and then reverted, but that's something we want to avoid. So yes, ofc there will be those that want to have their say on things sitting in the 5.0 branch that have otherwise met reviewer requirements, at the same time (as long as the branch remains limited in its scope) this does lengthen out the dev cycle for these contributions providing more patience and soak time for all. I would expect that the maintainers of the branch extend the opportunity for late reviewing to those that were doing The Right Thing focusing all their time on getting 4.0 out, before those commits go into trunk. Opposed to this, if we do these contributions in secret to avoid these types of discussions, only raising them once the feature-freeze is lifted, there may be a flood-gates rush and it will be even harder for folk to put in late reviews. I would certainly rather see exceptions made and things done in public (even if in a fork), though the main concern we are hearing is folk simply walking away altogether. I agree with the social responsibility perspective as well, but it's not something we can enforce. If folk want to do this we can't stop them and we should listen to why they believe it is a valuable exception. I do believe the discussion and hearing out people's frustrations: how overloaded and focused on 4.0 they are, and the concerns of how this risks delaying 4.0; should happen and is of immense value.
Re: Creating a branch for 5.0 …?
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" 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 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" 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. >
Re: Creating a branch for 5.0 …?
> > 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 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" 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 > >
Re: Creating a branch for 5.0 …?
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" wrote: > On Sep 10, 2020, at 2:42 PM, Benedict Elliott Smith 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
Re: Creating a branch for 5.0 …?
I second David. I think I can speak up here as I perfectly fit into the bucket of "new people trying to contribute". While it is true that reviews tend to take a long time I am perfectly happy with people who eventually look at them. It is understandable that there is a lot of going on and a committer / more experienced people do not have time to give a feedback immediately but as long as it is not forgotten completely (which has never happened to me), to me personally it does not matter too much how "fast" something is reviewed and merged even though I would be delighted if my changes are reviewed and merged faster (who would not not be, right?) I do not think that making yet another branch would make any significant difference, it can always be done against trunk and it would be harder to merge back as there might be a lot of conflicts etc ... Anyway, I am trying to go over tickets which are fixing and improving upcoming 4.0 and they are retrofitted into older branches if applicable. It is a very nice compromise. It gives signals to folks like "sure, we look into it, but if it fixes things in 4.0, it will be looked at even faster", so it motivates people to primarily focus on 4.0 which directly benefits the project to release 4.0 sooner. There is also an argument in this thread that having cassandra-5.0 would leave the burden of rebasing / fixing conflicts to respective contributors, quoting: "A cassandra-5.0 branch in-tree where the burden of maintenance would fall on people using the branch seems to mitigate that concern.". To be honest, I find myself preparing the branch for committers / reviewers perfectly fine and it is the minimum I can do so they do not have to - it is just a basic courtesy to prepare my work in such a way that it is reviewed comfortably and it can go straight in. I am even semi regularly ensuring that my open branches are on-par with the trunk every other day so once a comitter takes a look, everything is in place. I do not know if I am an exception but this is just natural process to me. Maybe the effort should be done in the area of getting more people on board technically so they can start to review things themselves (which indeed takes a lot of time and patience) instead of creating a new branch so they can pile up their stuff there. On Thu, 10 Sep 2020 at 22:25, David Capwell wrote: > > > > > The effort of the cassandra-5.0 branch maintenance: rebasing (git rerere); > > is just upon those that wish to take it on > > > I don't follow. If a bug fix goes into 4.0 do we not need to sync this > with 5.0, if so then this would be the 5th branch to keep in-sync, and if > the feature freeze is lifted then this branch may diverge making it harder > to apply the patch to. > > Tickets that have been reviewed and are (aside from the feature-freeze) > > ready to be committed, can be committed to the `cassandra-5.0` branch > > > Is there such a backlog of tickets that have been reviewed and not going > into 4.0.0? What I see are ideas and things punted from review, so it > would be good to see what this backlog is and how large. > > My main fear is reviews of new tickets. A complaint I have heard multiple > times from several people is that not enough people are reviewing and > reviews take a long time (number of reviewers is small and their backlog > keeps growing). If we open up reviews for non 4.0.0 work then my fear is > that even less review time will be allocated to 4.0.0 work. > > - who would be willing to help maintain this cassandra-5.0 branch? > > > I do not have the time so I will not be able to help with 5.0 work. > > - should it be kept external in a GH fork? Or would you rather have the > > branch in our main git repository? > > > To me GH fork is the same as not committed and not reviewed. If a fork > would help the community then I am ok with it, but I don't see it as ready > to commit. > > On Thu, Sep 10, 2020 at 12:58 PM Mick Semb Wever wrote: > > > We know we are turning away more and more contributions and new potential > > dev community with our 4.0 feature freeze, and it has been going on for a > > while now. > > > > I would like to suggest we create a cassandra-5.0 branch where we can start > > to queue up all reviewed and ready-to-go post-4.0 commits. > > > > This is not to distract from getting 4.0 out, where our primary focus is, > > but as a stop-gap in losing those contributions. The effort of the > > cassandra-5.0 branch maintenance: rebasing (git rerere); is just upon those > > that wish to take it on, and the branch can be located in whatever GH > > fork those > > individuals wish to keep it in. Tickets that have been reviewed and are > > (aside from the feature-freeze) ready to be committed, can be committed to > > the `cassandra-5.0` branch while their tickets remain in "Ready to Commit" > > status. The goal of this effort would be, a) we are giving the signal to > > contributors to get involved again (even while our primary focus in on > >
Re: Creating a branch for 5.0 …?
For significant new feature work, the option of working in a public, long-running, trunk-based feature branch is available. If we look at a specific example like CEP-7/SAI, I’m not sure how it would benefit much from a 5.0 branch, at least until it fundamentally depended on other 5.0-targeted work. > On Sep 10, 2020, at 11:39 PM, Dinesh Joshi wrote: > > >> >> On Sep 10, 2020, at 2:10 PM, Joshua McKenzie wrote: >> >> I can offer my anecdata: I know of two major enterprises as well as have >> had two interviewees unsolicited bring up to me that they have walked away >> from or bounced off the project due to the feature freeze / branching >> strategy. I may be the anomaly given the volume of people in the ecosystem >> I interact with, but I assume it's more than just the ones I've seen. > > Did these folks bring this issue up with dev@ or private@ before deciding to > go in a different direction? > > Dinesh > - > 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
