> 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.
I agree that everyone is free to work on whatever they want, but it seems like having a 4.next branch isn't a prerequisite for any new (or ongoing) development. I appreciate the cheerful tone in which this message was written, but I still think we should try and find an agreement on such things before putting them into action. On Thu, Sep 24, 2020 at 4:31 PM Brandon Williams <dri...@gmail.com> wrote: > 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 > > -- alex p
