On Fri, Sep 11, 2020 at 9:18 AM Joshua McKenzie <jmcken...@apache.org> 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 <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 > > > > >
