It's been a while now for this thread, but it seems to me that it has been established:
1. This is an opensource project and anyone is free to work on any part of it that they choose. Nobody has authority over this other than the contributor. 2. Some people are concerned that allowing innovation (in code) will make 4.0 take longer to release and cause them the pain of merging up yet another branch. So, here's what I've done, in an effort to make a space for both of these groups to operate: the exact same thing we've done for every release in the past. I created a branch for the 4.0 release. WHAT HAVE YOU DONE?! Alright, calm down. You're in group 2, don't worry: you have your 4.0 branch! You can completely focus on it, and if that's all you want to do, that's fine! YOU DO NOT NEED TO MERGE TO TRUNK. Those who wish to volunteer their time merging from 4.0 to trunk will pick up this mantle. If nobody does and I get exhausted, we'll just abort it and delete the branch, no big deal. One more time to make this crystal clear: IF YOU DO NOT WANT TO MERGE FROM 4.0 TO TRUNK, YOU ARE ABSOLVED FROM THIS DUTY. The branch is named, unsurprisingly, 'cassandra-4.0' As for those who wish to begin working on new features, trunk is now open for business. The merge order is now 2.1->2.2->3.0->3.11->4.0 and _optionally_, should you _choose_, trunk. The show must go on. On Wed, Sep 16, 2020 at 12:08 PM Dinesh Joshi <djo...@apache.org> wrote: > > Maybe you should ask these people to bring their contributions or issues > directly to the dev list. You don’t need to disclose their names or contact > information. > > Contributing to the project involves engaging the community. We’re still open > to discussions even if the patches may not land immediately. > > If they don’t talk to the dev list and won’t make a case for their > contribution (assuming it’s a big one) we can’t discuss possible ways forward > to accept it. > > It also seems that these folks are interested in contributing new features to > Cassandra. When the community is working towards stabilizing 4.0, > contributing to that effort will help build goodwill. We’re averse to one > off, drive-by contributions. I am not assuming that’s the case but the fact > is that we’re discussing 5.0 here. > > Dinesh > > > On Sep 16, 2020, at 6:00 AM, Joshua McKenzie <jmcken...@apache.org> wrote: > > > > People aren't lining up waiting to contribute to the project until we > > accept non-4.0 quality-based contributions. There is a discrete window of > > opportunity where we as a project can make a first impression on folks > > interested in joining our community, and signals from people, the data we > > have available about contributors, as well as basic logic are all > > consistent that we are turning away new contributors, likely permanently. > > They're moving on to other projects, since "apparently the Cassandra > > project isn't interested in new contributions" (interviewees words 2 weeks > > ago, not mine). Or same sentiment expressed by multiple major companies > > looking to find a storage coordination layer to put in front of their > > storage offerings, for instance. > > > > And sorry I can't give you specific names, dates, quotations, and/or > > contact information Benedict; it seems this rankles you as you continue to > > use terms like "hypothetical" and "mythical" to describe the very real > > humans I have spoken with over the course of the past year on this topic. > > If my constraints of confidentiality from the people I've interacted with > > are unacceptable for you in a discussion like this and you don't trust me > > enough to know I wouldn't overtly lie to try and shift an Overton Window, > > we should probably go ahead and agree to disagree on this conversation and > > let committers go forward and do what they think best for the project. > > > > > > > >> On Wed, Sep 16, 2020 at 5:09 AM, Benedict Elliott Smith > >> <bened...@apache.org > >>> wrote: > >> > >> I know. I recognise that is a frustrating aspect of this discussion. It is > >> something hard to move on. > >> > >> So how about we wait until there's a concrete example we can discuss as a > >> community? If we don't have one, it doesn't seem pressing. > >> > >> On 16/09/2020, 08:23, "Mick Semb Wever" <m...@apache.org> wrote: > >> > >> Can you provide some concrete examples of your own? > >> > >> On a tangent, I really appreciate the work done in the post-mortem > >> analysis of the 3.0 storage rewrite and just how long that took to find and > >> fix bugs it caused. The more of that we do the better our QA process will > >> become and the more we will feel justified/safe in raising concerns about > >> large patches coming in at the wrong time/place. > >> > >> Ironically, this entire proposal so far rests on hypothetical lost > >> contributions by hypothetical companies and individuals. > >> > >> I know. I recognise that is a frustrating aspect of this discussion. It is > >> something hard to move on. > >> > >> I would also like to take issue with a talking point running through much > >> of this discussion, that those who are focused on quality assurance have > >> "different priorities" to those who now want to ship features into 5.0: we > >> also want to ship features, we're just doing the work the project agreed > >> upon as a prerequisite to that. > >> > >> Yes, we have to keep bringing this back to the context that this is an > >> exception we would be making for specific new contributors we recognise we > >> would otherwise lose. > >> > >> An analogy I see here is how the open source work is done out in the open > >> but sometimes with new contributors we may make the exception to mentor > >> them through a patch or two in private to give them a safe space to build > >> confidence before meeting community rules and precedence. > >> > >> I'm hoping that the community transcends the "QA vs New Features" > >> dichotomy, e.g. with good CI/CD. I think this is now the project's biggest > >> potential with how the PMC is now spread. That said, AFAIK we are still > >> waiting on testing/QA requirements/clarifications for 4.0-rc. The best > >> opportunity we have for QA/CI improvements that will be foundational post > >> 4.0 is now. > >> > >> --------------------------------------------------------------------- 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
