> > What are you basing this harmful supposition on? > ascribing negative intentions or motives to others without good reason. It > is not good for you, or the community. > I certainly don't want you worried about my wellbeing on account of this dialog; it's always good to be reminded about our shared concern for each other as humans and the project's health in interactions like this though! Just so you don't need to worry about me and to hopefully help clarify for readers: I personally strongly believe *everyone* on this thread's intentions and motives are nothing more or less than the long-term wellbeing of the project. Full stop. We definitely don't appear to all agree on the best way to get there, but at least I personally don't question that as being everyone's goal. If that's coming across in my verbiage I'll happily work on improving that; DM's with pointers welcome.
To clarify a hypothetical in which I think discouraging contributions from some sources would be very appropriate and not harmful in any way, "we should discourage people who are 1st year in university who have never used Java nor worked on infrastructure code from trying to contribute rewrites of things like Gossip or our StorageEngine." This seems like a pretty reasonable statement in my opinion. No negative intentions or motives, just the constraints of reality. It's a continuum, and there's a lot of things in this codebase that are more complex with longer histories than others, and varying levels of skill (and perceptions of each others' level of skill!) to further complicate things. In the 6.5 years I've spent on the project, we have a strong and consistent culture of both dropping gigantic multi-tens-of-thousands of line squashed atomic changes on each other and then rewriting each others' code en masse (sometimes before it's even released!) instead of working in small increments and reverting when deemed appropriate [1]. I think a completely rational way to try and mitigate the downsides of these patterns would be for an individual to think and/or say "Hey, please hold off on writing that until I can engage. I have a point of view but don't have time to engage right now (or will have to stop working on other things I consider critical) and I don't want to have to rewrite this stuff later to address issues that I fear will be overlooked. Fixing after merge is 10x harder than at design, and 10x harder when it's out in production, etc". Ergo, people working on 4.0 would feel the obligation to dilute their investment on 4.0 to engage on these other efforts. A very rational PoV IMO. 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 > Structurally in terms of social dynamics, it seems like things mostly hinge on whether or not committers trust each other to do the work to a high bar of quality that they're focused on doing and accepting that there are differing views on how to achieve our shared priority of Cassandra's long-term success. Ultimately I would contend we haven't historically had the coding hygiene, behavioral expectations, or quality tooling to make this need for trust unnecessary, though we're making progress there. That said, regardless of these dynamics there are fundamentals to how Apache projects operate, and I think it's valuable to quote Jeff here: > 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. > It's my earnest hope that continuing dialog like this proves constructive for the project rather than destructive. Navigating the Innovator's Dilemma [2] on a project as old and as widely adopted as Cassandra is a very real challenge. [1]: http://community.apache.org/committers/lazyConsensus.html [2]: https://en.wikipedia.org/wiki/The_Innovator%27s_Dilemma p.s. - sorry for being long-winded. Lots of complex stuff to cover here. On Sat, Sep 12, 2020 at 5:46 PM Benedict Elliott Smith <bened...@apache.org> wrote: > > 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. > > This is directly contrary to the evidence I have seen. Proponents of the > status quo have expressly encouraged more contributions that are compatible > with the freeze, and at most a postponement has been suggested for > contributions that are incompatible with the freeze. What are you basing > this harmful supposition on? > > I would ask you to try really hard to break this pattern, of ascribing > negative intentions or motives to others without good reason. It is not > good for you, or the community. > > On 11/09/2020, 20:27, "Joshua McKenzie" <jmcken...@apache.org> wrote: > > 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 <jorda...@gmail.com> > wrote: > > > 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 > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
