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 <jorda...@gmail.com> 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 <benedict@apache. > 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" <m...@apache.org> 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 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. > > --------------------------------------------------------------------- To > unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional > commands, e-mail: dev-h...@cassandra.apache.org > >
