You do not have the authority to unilaterally overrule the community process.
This is a serious breach of your responsibilities as a member of the PMC.
I have deleted this branch, and will do so again if you repeat this.
As discussed, nobody can police what you work on, but the community does decide
what is merged. Today the community still has in force an explicit vote
prohibiting thee merge of this work. You must conduct a vote to rescind this
decision.
Given the proposers of this policy have failed to respond to the most recent
query on the topic, that would also seem very problematic to me.
On 24/09/2020, 15:31, "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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
