Re: Creating a branch for 5.0 …?

[Jordan West]

On Thu, Sep 24, 2020 at 10:19 AM Joshua McKenzie 
wrote:

> Jordan: thanks for providing that context - it's quite helpful. Was that
> aspect of the conversation captured and shared with the rest of the project
> on the mailing list? It's a shame if not, since that may have contributed
> quite a bit to misalignment and misunderstanding over time.


Unfortuantely, I don't believe it was. The discussion occurred between
committers/contributors/PMC members on the floor in the venue and was
brought to the mailing list for a vote to ensure everyone was included. It
certainly would have been better if we were able to capture more of it (we
took as many notes as we could and translated them into that wiki doc but
there was no ability to record/etc). While its true that even more detail
would have been helpful, many of the folks who are pushing back against
what was discussed there were not in attendance or active in the open
source project at the time.

>
> Fewer and fewer people have the appetite to deal with this bickering and
> exposing anyone new to this seems like a guaranteed way to turn them away
> from the project for good.
>

Speaking for myself, the tone and tenor, in addition to the lack of
progress, in these discussions have absolutely affected my desire to
participate in the open source project (from taking additional reviews that
would speed up 4.0 on my free time, to encouraging new community members to
join, to participating in these discussions entirely). I hope we can find a
better way to communicate.

One suggestion I have for folks participating is to consider what feedback
is best given on the public mailing list and what feedback is better
delivered directly. We don't have to do EVERYTHING on the public mailing
list. Only the parts that pertain to Cassandra. And sometimes we can
resolve our personal differences better when there isn't an additional
audience around.


>
>
> On Thu, Sep 24, 2020 at 12:22 PM, Benedict Elliott Smith <
> bened...@apache.org> wrote:
>
> > The discussion on the present topic has not concluded, and if we are
> > making an exception to 4.0 only then it really needs to.
> >
> > Members of one organisation have been pushing hard for feature
> development
> > to proceed, arguing it harms unnamed third parties. A request that these
> > third parties be asked to participate in the discussion has so far gone
> > unanswered. It is reasonable that this is answered before a vote, since
> > this is the entire basis of the argument in favour of branching.
> >
> > Given this is the basis of argument, I would also propose a less
> > contentious vote, should one be undertaken: to create a cassandra-5.0
> > branch that is open only to contributions from those unaffiliated by
> > employment with any existing committers. This seems to alleviate the
> > concerns precipitating this discussion, while mitigating the concerns of
> > those who are opposed to it.
> >
> > On 24/09/2020, 17:02, "Jake Luciani"  wrote:
> >
> > The vote was to unfreeze new changes at beta, so logically that means
> > non-bugfix work goes into trunk.
> >
> > Jordan, thanks. That is a more recent vote so thanks. That being said,
> > under that line Benedict comments this needs to be discussed. So how
> about
> > we just have a Vote on branching cassandra-4.0 and the issue will be
> > decided?
> >
> > Jake
> >
> > On Thu, Sep 24, 2020 at 11:53 AM Benedict Elliott Smith  > org> wrote:
> >
> > I'm not sure what you are referring to here, that vote said nothing about
> > branching at beta.
> >
> > The most recent vote on the topic anyway was for the Release Lifecycle
> > process, which stipulates branching at GA.
> >
> > https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
> >
> > We can vote to modify this document, or to make an exception, but I am
> > aware of no other vote stipulating anything about the point at which we
> > branch.
> >
> > On 24/09/2020, 16:49, "Jake Luciani"  wrote:
> >
> > Today the community still has in force an explicit vote prohibiting
> >
> > thee
> > merge of this work.
> >
> > You referred to an explicit vote here. I assume that was the one you were
> > referring to? Yes, the community should decide.
> > Call a vote if you think the community thinks we should continue the
> > freeze
> > vs continuing to rely on beliefs about the community.
> >
> > I'm simply pointing out the branching of 4.0 post beta was the plan of
> > last
> > record.
> >
> > Jake
> >
> > On Thu, Sep 24, 2020 at 11:44 AM Benedict Elliott Smith <
> benedict@apache.
> > org>
> > wrote:
> >
> > The community does everything through discussion and consensus.
> >
> > Does that
> >
> > include branching, or not?
> >
> > If there is no consensus, a vote is held. Whether or not you
> >
> > consider the
> >
> > vote from 2018 still valid, you still need to seek the consent of the
> > community for your action today. Or is that not sacrosanct anymore?
> >
> > On 24/09/2020, 16:22, "Jake Luciani"  wrote:
> 

Re: Creating a branch for 5.0 …?

[Dinesh Joshi]

Josh,

> For what it's worth, when I engage with other people working on large forks
> that want to bring their features back to the project, the absolute last
> thing I want to do to them is throw them into email threads like this.

People need to positively engage with the community, have discussions & debate 
their PoV to get their contributions into the official codebase.

The CEP explicitly helps do just that. Creating a 5.0 branch implies that these 
parties just want to drop code rather than actually discuss their features with 
the community. This is the disconnect for me personally.

People who run large forks, should also care about what the community is 
working on. If they open up a CEP or Discuss thread, I don't think it'll be 
remotely as contentious as this thread.

> Fewer and fewer people have the appetite to deal with this bickering and 
> exposing anyone new to this seems like a guaranteed way to turn them away 
> from the project for good.

Debate is healthy and its important for the long-term health of this project.


Dinesh
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Creating a branch for 5.0 …?

[Brandon Williams]

On Thu, Sep 24, 2020 at 1:14 PM sankalp kohli  wrote:

> I think it is important to think why we are here. We are here as we shipped
> 3.0 with 10s of correctness bug. So the statements should be
> "3.0 shipped with 10s of correctness bugs and that is causing contributions
> to go away and stopping innovation"

I think we're making logical leaps again without any real foundation,
it could be argued that innovation
 is not happening because there is no place for it to happen just as easily.

> "Lack of 4.0 release due to 3.0 shipping with 10s of correctness bugs is
> causing people to think C* is dead."

This is probably true.

> Once we start putting it this way, we can start debating on how not to make
> 4.0 like 3.0 and cause 5.0 to be delayed.

This again seems based on an assumption that allowing feature work
will deter correctness work.  Is there any evidence of that, with the
merge onus removed?

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Creating a branch for 5.0 …?

[sankalp kohli]

Hi,
I hear the following
"Freeze is causing contributions to go away and stopping innovation"
"Lack of 4.0 release is causing people to think C* is dead."

I think it is important to think why we are here. We are here as we shipped
3.0 with 10s of correctness bug. So the statements should be
"3.0 shipped with 10s of correctness bugs and that is causing contributions
to go away and stopping innovation"
"Lack of 4.0 release due to 3.0 shipping with 10s of correctness bugs is
causing people to think C* is dead."

Once we start putting it this way, we can start debating on how not to make
4.0 like 3.0 and cause 5.0 to be delayed. So instead of focusing on
symptoms and major effects 3.0 + correctness bugs has caused, lets talk
about following

1. How can we make 4.0 stable so we dont have to freeze for 2+ years and
dont ship with 10s of correctness bugs.
2. How can we have a stable .0 release instead of people not using it for
10th minor.
3. How can we have a predictable timeline for major releases like 4.0 so
contributors/users knows how to plan around it.

I think it is more important to fix the root cause than fixing the
symptoms.

Thanks,
Sankalp






On Thu, Sep 24, 2020 at 10:50 AM Brandon Williams  wrote:

> On Thu, Sep 24, 2020 at 12:22 PM sankalp kohli 
> wrote:
> >
> > Hi Brandon,
> >   In all respect, we need to discuss and vote before we
> > create a new branch. So it is best if we do that instead of creating
> > branches.
>
> Fair enough.
>
> > Freeze is a symptom not a cause so if we dont like the symptom,
> > we should see how to fix the cause. Are we fine having a database release
> > which will be released with 10s of  correctness bugs and with an implicit
> > assumption that no one will use it in prod till 10th minor.
>
> I think we're making quite a leap to go from adding new features in
> one branch equating to releasing software with more bugs in a
> completely different branch.  I think your concern is that by having
> the project 'bless' a feature-accepting branch, this will detract from
> time they would otherwise spend on stabilizing the release branch (if
> we had one.)  I can't fault you for this, it may be a real
> possibility, nobody knows.  Nothing can be done about changing what
> people decide to work on in a free project, however, and it would be
> naive to think there are not people already out there interested in
> working purely on new features, with no dog in the stability of 4.0
> fight.  I know that's not conducive to your goals (and honestly I'd
> rather they help on the 4.0 side too) but that's just the way things
> are.
>
> > Everyone wants to innovate but security, durability and availability
> comes
> > first.  People who are working on stabilizing 4.0 are doing it as there
> is
> > no other choice. So I request you to kindly cooperate on working with
> them
> > in making 4.0 a stable release.
>
> Sorry, but I respectfully refuse your statement that there is no other
> choice.  This is a free project and there is always a choice for those
> who may wish to donate their time.  I would like to cast a wide enough
> net to allow all their itches to be scratched here for the future
> health of this project.
>
> Kind Regards,
> Brandon
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Creating a branch for 5.0 …?

[Brandon Williams]

On Thu, Sep 24, 2020 at 12:22 PM sankalp kohli  wrote:
>
> Hi Brandon,
>   In all respect, we need to discuss and vote before we
> create a new branch. So it is best if we do that instead of creating
> branches.

Fair enough.

> Freeze is a symptom not a cause so if we dont like the symptom,
> we should see how to fix the cause. Are we fine having a database release
> which will be released with 10s of  correctness bugs and with an implicit
> assumption that no one will use it in prod till 10th minor.

I think we're making quite a leap to go from adding new features in
one branch equating to releasing software with more bugs in a
completely different branch.  I think your concern is that by having
the project 'bless' a feature-accepting branch, this will detract from
time they would otherwise spend on stabilizing the release branch (if
we had one.)  I can't fault you for this, it may be a real
possibility, nobody knows.  Nothing can be done about changing what
people decide to work on in a free project, however, and it would be
naive to think there are not people already out there interested in
working purely on new features, with no dog in the stability of 4.0
fight.  I know that's not conducive to your goals (and honestly I'd
rather they help on the 4.0 side too) but that's just the way things
are.

> Everyone wants to innovate but security, durability and availability comes
> first.  People who are working on stabilizing 4.0 are doing it as there is
> no other choice. So I request you to kindly cooperate on working with them
> in making 4.0 a stable release.

Sorry, but I respectfully refuse your statement that there is no other
choice.  This is a free project and there is always a choice for those
who may wish to donate their time.  I would like to cast a wide enough
net to allow all their itches to be scratched here for the future
health of this project.

Kind Regards,
Brandon

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Creating a branch for 5.0 …?

[sankalp kohli]

Hi Brandon,
  In all respect, we need to discuss and vote before we
create a new branch. So it is best if we do that instead of creating
branches. Freeze is a symptom not a cause so if we dont like the symptom,
we should see how to fix the cause. Are we fine having a database release
which will be released with 10s of  correctness bugs and with an implicit
assumption that no one will use it in prod till 10th minor.

Everyone wants to innovate but security, durability and availability comes
first.  People who are working on stabilizing 4.0 are doing it as there is
no other choice. So I request you to kindly cooperate on working with them
in making 4.0 a stable release.

https://tinyurl.com/30seriousissues


Thanks,
Sankalp

On Thu, Sep 24, 2020 at 9:30 AM Brandon Williams  wrote:

> On Thu, Sep 24, 2020 at 11:22 AM Benedict Elliott Smith
>  wrote:
> > Given this is the basis of argument, I would also propose a less
> contentious vote, should one be undertaken: to create a cassandra-5.0
> branch that is open only to contributions from those unaffiliated by
> employment with any existing committers.
>
> Are you serious?  What kind of opensource environment is it that
> precludes anyone from contributing based on their employment?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Creating a branch for 5.0 …?

[Joshua McKenzie]

this is the basis of argument,

This is incorrect. The basis of the argument was Mick's point of view he
expressed as an individual on the project, which is that projects that turn
away contributions or try and force people into contributing in certain
ways are not long for this world. A very basic logical argument with a lot
of individual experience backing it up; anecdata I felt it appropriate to
share knowing there are limitations on how much detail I can disclose. Also
not consistent with the Apache Way, as Jeff pointed out.

You keep trying to bend this to a discussion about my credibility and about
DataStax' incentives. If you think I'm lying to try and shift the project,
please say so and stop hiding behind terms like "mythical" or
"hypothetical".

This is individuals on the project who care deeply about its welfare with
points of view that strongly differ from yours, *as individual humans.*

Much like another *individual human and committer *coming out of the
woodwork to open up a bunch of tickets this week for post 4.0.

Much like me waking up to Brandon this morning with him choosing to do
this *because
he as a human being is worried about the long-term health of the project.*

Feel free to engage with us as the individual humans we are. Please stop
trying to turn this discussion into an argument between talking heads
advocating for what their respective companies are coercing them to do. We
in the Cassandra engineering community are fortunate enough that our skills
are in very high demand; in all likelihood people are working where they
are because they share philosophical perspectives with the people they work
with, not because of some top-down institutional mandate on them.

For what it's worth, when I engage with other people working on large forks
that want to bring their features back to the project, the absolute last
thing I want to do to them is throw them into email threads like this.
Fewer and fewer people have the appetite to deal with this bickering and
exposing anyone new to this seems like a guaranteed way to turn them away
from the project for good.

Jordan: thanks for providing that context - it's quite helpful. Was that
aspect of the conversation captured and shared with the rest of the project
on the mailing list? It's a shame if not, since that may have contributed
quite a bit to misalignment and misunderstanding over time.


On Thu, Sep 24, 2020 at 12:22 PM, Benedict Elliott Smith <
bened...@apache.org> wrote:

> The discussion on the present topic has not concluded, and if we are
> making an exception to 4.0 only then it really needs to.
>
> Members of one organisation have been pushing hard for feature development
> to proceed, arguing it harms unnamed third parties. A request that these
> third parties be asked to participate in the discussion has so far gone
> unanswered. It is reasonable that this is answered before a vote, since
> this is the entire basis of the argument in favour of branching.
>
> Given this is the basis of argument, I would also propose a less
> contentious vote, should one be undertaken: to create a cassandra-5.0
> branch that is open only to contributions from those unaffiliated by
> employment with any existing committers. This seems to alleviate the
> concerns precipitating this discussion, while mitigating the concerns of
> those who are opposed to it.
>
> On 24/09/2020, 17:02, "Jake Luciani"  wrote:
>
> The vote was to unfreeze new changes at beta, so logically that means
> non-bugfix work goes into trunk.
>
> Jordan, thanks. That is a more recent vote so thanks. That being said,
> under that line Benedict comments this needs to be discussed. So how about
> we just have a Vote on branching cassandra-4.0 and the issue will be
> decided?
>
> Jake
>
> On Thu, Sep 24, 2020 at 11:53 AM Benedict Elliott Smith  org> wrote:
>
> I'm not sure what you are referring to here, that vote said nothing about
> branching at beta.
>
> The most recent vote on the topic anyway was for the Release Lifecycle
> process, which stipulates branching at GA.
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
>
> We can vote to modify this document, or to make an exception, but I am
> aware of no other vote stipulating anything about the point at which we
> branch.
>
> On 24/09/2020, 16:49, "Jake Luciani"  wrote:
>
> Today the community still has in force an explicit vote prohibiting
>
> thee
> merge of this work.
>
> You referred to an explicit vote here. I assume that was the one you were
> referring to? Yes, the community should decide.
> Call a vote if you think the community thinks we should continue the
> freeze
> vs continuing to rely on beliefs about the community.
>
> I'm simply pointing out the branching of 4.0 post beta was the plan of
> last
> record.
>
> Jake
>
> On Thu, Sep 24, 2020 at 11:44 AM Benedict Elliott Smith < benedict@apache.
> org>
> wrote:
>
> The community does everything through discussion and consensus.
>
> Does that
>

Re: Creating a branch for 5.0 …?

[Brandon Williams]

On Thu, Sep 24, 2020 at 11:22 AM Benedict Elliott Smith
 wrote:
> Given this is the basis of argument, I would also propose a less contentious 
> vote, should one be undertaken: to create a cassandra-5.0 branch that is open 
> only to contributions from those unaffiliated by employment with any existing 
> committers.

Are you serious?  What kind of opensource environment is it that
precludes anyone from contributing based on their employment?

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Creating a branch for 5.0 …?

[Benedict Elliott Smith]

The discussion on the present topic has not concluded, and if we are making an 
exception to 4.0 only then it really needs to.

Members of one organisation have been pushing hard for feature development to 
proceed, arguing it harms unnamed third parties.  A request that these third 
parties be asked to participate in the discussion has so far gone unanswered.  
It is reasonable that this is answered before a vote, since this is the entire 
basis of the argument in favour of branching.

Given this is the basis of argument, I would also propose a less contentious 
vote, should one be undertaken: to create a cassandra-5.0 branch that is open 
only to contributions from those unaffiliated by employment with any existing 
committers.  This seems to alleviate the concerns precipitating this 
discussion, while mitigating the concerns of those who are opposed to it.



On 24/09/2020, 17:02, "Jake Luciani"  wrote:

The vote was to unfreeze new changes at beta, so logically that means
non-bugfix work goes into trunk.

Jordan, thanks.   That is a more recent vote so thanks.  That being said,
under that line Benedict comments this needs to be discussed.
So how about we just have a Vote on branching cassandra-4.0 and the issue
will be decided?

Jake




On Thu, Sep 24, 2020 at 11:53 AM Benedict Elliott Smith 

wrote:

> I'm not sure what you are referring to here, that vote said nothing about
> branching at beta.
>
> The most recent vote on the topic anyway was for the Release Lifecycle
> process, which stipulates branching at GA.
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
>
> We can vote to modify this document, or to make an exception, but I am
> aware of no other vote stipulating anything about the point at which we
> branch.
>
>
> On 24/09/2020, 16:49, "Jake Luciani"  wrote:
>
> > Today the community still has in force an explicit vote prohibiting
> thee
> merge of this work.
>
> You referred to an explicit vote here.  I assume that was the one you
> were
> referring to?  Yes, the community should decide.
> Call a vote if you think the community thinks we should continue the
> freeze
> vs continuing to rely on beliefs about the community.
>
> I'm simply pointing out the branching of 4.0 post beta was the plan of
> last
> record.
>
> Jake
>
> On Thu, Sep 24, 2020 at 11:44 AM Benedict Elliott Smith <
> bened...@apache.org>
> wrote:
>
> > The community does everything through discussion and consensus.
> Does that
> > include branching, or not?
> >
> > If there is no consensus, a vote is held.  Whether or not you
> consider the
> > vote from 2018 still valid, you still need to seek the consent of 
the
> > community for your action today.  Or is that not sacrosanct anymore?
> >
> >
> > On 24/09/2020, 16:22, "Jake Luciani"  wrote:
> >
> > I'm sorry I see no issue with branching 4.0 as it was the thing
> we
> > voted on
> > back in 2018.  If you wish to extend the freeze you should call
> a new
> > vote.
> >
> > On Thu, Sep 24, 2020 at 11:15 AM Benedict Elliott Smith <
> > bened...@apache.org>
> > wrote:
> >
> > > Nobody has any problem with an external repository being
> > maintained.  Just
> > > bear in mind the normal process will need to take place to
> merge to
> > the ASF
> > > repository, and that there may be feedback and review requests
> to
> > address,
> > > so merge order and diffs will probably change.
> > >
> > >
> > > On 24/09/2020, 16:05, "Brandon Williams" 
> wrote:
> > >
> > > On Thu, Sep 24, 2020 at 9:55 AM Benedict Elliott Smith
> > >  wrote:
> > > >
> > > > 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.
> > >
> > > Feel free to complain that I'm creating branches we intend
> to
> > someday,
> > > perhaps even in 2020, release.
> > >
> > > > I have deleted this branch, and will do so again if you
> repeat
> > this.
> > >
> > > This would create some interesting tickets for INFRA, but
> I won't
> > > waste their time with you either. Whether either of us has
> the
> > > authority to do such on ASF infrastructure is irrelevant,
> 

Re: Creating a branch for 5.0 …?

[Jordan West]

The intention was the former. It was discussed during apache con in 2019
and many people expressed the desire to wait until GA. Even some who
initially were opposed to the freeze.


Jordan

On Thu, Sep 24, 2020 at 9:04 AM Joshua McKenzie 
wrote:

>
> https://lists.apache.org/thread.html/5ee66f3986bf8308912c216bd1b5f9aea35443626db9f92cdca4d7b9%40%3Cdev.cassandra.apache.org%3E
>
>
>
> "*From: *sankalp kohli 
>
> *To: *dev 
>
> *Subject: *Re: [VOTE] Branching Change for 4.0 Freeze
>
> *Date: *2018/07/11 21:50:08
>
> *List: *dev@cassandra.apache.org
>
> 
>
>
>
> We will be in this state till beta is reached."
>
>
>
> The release lifecycle doc says: "*A new branch is created for the release
>
> with the new major version, limiting any new feature addition to the new
>
> release branch, with new feature development will continue to happen only
>
> on trunk.*"
>
>
>
> This could be read as "we won't branch until we hit GA" or "we will make
>
> sure we definitely branch at GA so disruptive features don't go into it",
>
> the latter of which is what we've done in all prior releases. I'm curious
>
> if there was any point in that discussion where the intention was made
>
> explicit if anyone has a link.
>
>
>
>
>
>
>
> On Thu, Sep 24, 2020 at 11:53 AM, Benedict Elliott Smith <
>
> bened...@apache.org> wrote:
>
>
>
> > I'm not sure what you are referring to here, that vote said nothing about
>
> > branching at beta.
>
> >
>
> > The most recent vote on the topic anyway was for the Release Lifecycle
>
> > process, which stipulates branching at GA.
>
> >
>
> > https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
>
> >
>
> > We can vote to modify this document, or to make an exception, but I am
>
> > aware of no other vote stipulating anything about the point at which we
>
> > branch.
>
> >
>
> > On 24/09/2020, 16:49, "Jake Luciani"  wrote:
>
> >
>
> > Today the community still has in force an explicit vote prohibiting thee
>
> >
>
> > merge of this work.
>
> >
>
> > You referred to an explicit vote here. I assume that was the one you were
>
> > referring to? Yes, the community should decide.
>
> > Call a vote if you think the community thinks we should continue the
>
> > freeze vs continuing to rely on beliefs about the community.
>
> >
>
> > I'm simply pointing out the branching of 4.0 post beta was the plan of
>
> > last record.
>
> >
>
> > Jake
>
> >
>
> > On Thu, Sep 24, 2020 at 11:44 AM Benedict Elliott Smith 
> > org> wrote:
>
> >
>
> > The community does everything through discussion and consensus. Does that
>
> > include branching, or not?
>
> >
>
> > If there is no consensus, a vote is held. Whether or not you consider the
>
> > vote from 2018 still valid, you still need to seek the consent of the
>
> > community for your action today. Or is that not sacrosanct anymore?
>
> >
>
> > On 24/09/2020, 16:22, "Jake Luciani"  wrote:
>
> >
>
> > I'm sorry I see no issue with branching 4.0 as it was the thing we voted
>
> > on
>
> > back in 2018. If you wish to extend the freeze you should call a new
> vote.
>
> >
>
> > On Thu, Sep 24, 2020 at 11:15 AM Benedict Elliott Smith <
> benedict@apache.
>
> > org>
>
> > wrote:
>
> >
>
> > Nobody has any problem with an external repository being
>
> >
>
> > maintained. Just
>
> >
>
> > bear in mind the normal process will need to take place to merge to
>
> >
>
> > the ASF
>
> >
>
> > repository, and that there may be feedback and review requests to
>
> >
>
> > address,
>
> >
>
> > so merge order and diffs will probably change.
>
> >
>
> > On 24/09/2020, 16:05, "Brandon Williams"  wrote:
>
> >
>
> > On Thu, Sep 24, 2020 at 9:55 AM Benedict Elliott Smith
>
> >  wrote:
>
> >
>
> > 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.
>
> >
>
> > Feel free to complain that I'm creating branches we intend to
>
> >
>
> > someday,
>
> >
>
> > perhaps even in 2020, release.
>
> >
>
> > I have deleted this branch, and will do so again if you repeat
>
> >
>
> > this.
>
> >
>
> > This would create some interesting tickets for INFRA, but I won't waste
>
> > their time with you either. Whether either of us has the authority to do
>
> > such on ASF infrastructure is irrelevant, since
>
> >
>
> > that
>
> >
>
> > is the only thing that can be argued here. The ASL absolutely
>
> >
>
> > allows
>
> >
>
> > people to innovate on their own with the code, so let's just
>
> >
>
> > move the
>
> >
>
> > bits.
>
> >
>
> > Those who wish to innovate,
>
> > https://github.com/driftx/cassandra/tree/cassandra-5.0 is now
>
> >
>
> > open for
>
> >
>
> > business, PRs accepted. This will be maintained to track trunk
>
> >
>
> > on the
>
> >
>
> > ASF servers.
>
> >
>
> > I guess this is the apache way.
>
> >
>
> > 

Re: Creating a branch for 5.0 …?

[Joshua McKenzie]

https://lists.apache.org/thread.html/5ee66f3986bf8308912c216bd1b5f9aea35443626db9f92cdca4d7b9%40%3Cdev.cassandra.apache.org%3E

"*From: *sankalp kohli 
*To: *dev 
*Subject: *Re: [VOTE] Branching Change for 4.0 Freeze
*Date: *2018/07/11 21:50:08
*List: *dev@cassandra.apache.org


We will be in this state till beta is reached."

The release lifecycle doc says: "*A new branch is created for the release
with the new major version, limiting any new feature addition to the new
release branch, with new feature development will continue to happen only
on trunk.*"

This could be read as "we won't branch until we hit GA" or "we will make
sure we definitely branch at GA so disruptive features don't go into it",
the latter of which is what we've done in all prior releases. I'm curious
if there was any point in that discussion where the intention was made
explicit if anyone has a link.



On Thu, Sep 24, 2020 at 11:53 AM, Benedict Elliott Smith <
bened...@apache.org> wrote:

> I'm not sure what you are referring to here, that vote said nothing about
> branching at beta.
>
> The most recent vote on the topic anyway was for the Release Lifecycle
> process, which stipulates branching at GA.
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
>
> We can vote to modify this document, or to make an exception, but I am
> aware of no other vote stipulating anything about the point at which we
> branch.
>
> On 24/09/2020, 16:49, "Jake Luciani"  wrote:
>
> Today the community still has in force an explicit vote prohibiting thee
>
> merge of this work.
>
> You referred to an explicit vote here. I assume that was the one you were
> referring to? Yes, the community should decide.
> Call a vote if you think the community thinks we should continue the
> freeze vs continuing to rely on beliefs about the community.
>
> I'm simply pointing out the branching of 4.0 post beta was the plan of
> last record.
>
> Jake
>
> On Thu, Sep 24, 2020 at 11:44 AM Benedict Elliott Smith  org> wrote:
>
> The community does everything through discussion and consensus. Does that
> include branching, or not?
>
> If there is no consensus, a vote is held. Whether or not you consider the
> vote from 2018 still valid, you still need to seek the consent of the
> community for your action today. Or is that not sacrosanct anymore?
>
> On 24/09/2020, 16:22, "Jake Luciani"  wrote:
>
> I'm sorry I see no issue with branching 4.0 as it was the thing we voted
> on
> back in 2018. If you wish to extend the freeze you should call a new vote.
>
> On Thu, Sep 24, 2020 at 11:15 AM Benedict Elliott Smith < benedict@apache.
> org>
> wrote:
>
> Nobody has any problem with an external repository being
>
> maintained. Just
>
> bear in mind the normal process will need to take place to merge to
>
> the ASF
>
> repository, and that there may be feedback and review requests to
>
> address,
>
> so merge order and diffs will probably change.
>
> On 24/09/2020, 16:05, "Brandon Williams"  wrote:
>
> On Thu, Sep 24, 2020 at 9:55 AM Benedict Elliott Smith
>  wrote:
>
> 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.
>
> Feel free to complain that I'm creating branches we intend to
>
> someday,
>
> perhaps even in 2020, release.
>
> I have deleted this branch, and will do so again if you repeat
>
> this.
>
> This would create some interesting tickets for INFRA, but I won't waste
> their time with you either. Whether either of us has the authority to do
> such on ASF infrastructure is irrelevant, since
>
> that
>
> is the only thing that can be argued here. The ASL absolutely
>
> allows
>
> people to innovate on their own with the code, so let's just
>
> move the
>
> bits.
>
> Those who wish to innovate,
> https://github.com/driftx/cassandra/tree/cassandra-5.0 is now
>
> open for
>
> business, PRs accepted. This will be maintained to track trunk
>
> on the
>
> ASF servers.
>
> I guess this is the apache way.
>
> -
>
> 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
>
> --
> http://twitter.com/tjake
>
> - To
> unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional
> commands, e-mail: dev-h...@cassandra.apache.org
>
> --
> http://twitter.com/tjake
>
> - To
> unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional
> commands, e-mail: dev-h...@cassandra.apache.org
>

Re: Creating a branch for 5.0 …?

[Jake Luciani]

The vote was to unfreeze new changes at beta, so logically that means
non-bugfix work goes into trunk.

Jordan, thanks.   That is a more recent vote so thanks.  That being said,
under that line Benedict comments this needs to be discussed.
So how about we just have a Vote on branching cassandra-4.0 and the issue
will be decided?

Jake




On Thu, Sep 24, 2020 at 11:53 AM Benedict Elliott Smith 
wrote:

> I'm not sure what you are referring to here, that vote said nothing about
> branching at beta.
>
> The most recent vote on the topic anyway was for the Release Lifecycle
> process, which stipulates branching at GA.
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
>
> We can vote to modify this document, or to make an exception, but I am
> aware of no other vote stipulating anything about the point at which we
> branch.
>
>
> On 24/09/2020, 16:49, "Jake Luciani"  wrote:
>
> > Today the community still has in force an explicit vote prohibiting
> thee
> merge of this work.
>
> You referred to an explicit vote here.  I assume that was the one you
> were
> referring to?  Yes, the community should decide.
> Call a vote if you think the community thinks we should continue the
> freeze
> vs continuing to rely on beliefs about the community.
>
> I'm simply pointing out the branching of 4.0 post beta was the plan of
> last
> record.
>
> Jake
>
> On Thu, Sep 24, 2020 at 11:44 AM Benedict Elliott Smith <
> bened...@apache.org>
> wrote:
>
> > The community does everything through discussion and consensus.
> Does that
> > include branching, or not?
> >
> > If there is no consensus, a vote is held.  Whether or not you
> consider the
> > vote from 2018 still valid, you still need to seek the consent of the
> > community for your action today.  Or is that not sacrosanct anymore?
> >
> >
> > On 24/09/2020, 16:22, "Jake Luciani"  wrote:
> >
> > I'm sorry I see no issue with branching 4.0 as it was the thing
> we
> > voted on
> > back in 2018.  If you wish to extend the freeze you should call
> a new
> > vote.
> >
> > On Thu, Sep 24, 2020 at 11:15 AM Benedict Elliott Smith <
> > bened...@apache.org>
> > wrote:
> >
> > > Nobody has any problem with an external repository being
> > maintained.  Just
> > > bear in mind the normal process will need to take place to
> merge to
> > the ASF
> > > repository, and that there may be feedback and review requests
> to
> > address,
> > > so merge order and diffs will probably change.
> > >
> > >
> > > On 24/09/2020, 16:05, "Brandon Williams" 
> wrote:
> > >
> > > On Thu, Sep 24, 2020 at 9:55 AM Benedict Elliott Smith
> > >  wrote:
> > > >
> > > > 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.
> > >
> > > Feel free to complain that I'm creating branches we intend
> to
> > someday,
> > > perhaps even in 2020, release.
> > >
> > > > I have deleted this branch, and will do so again if you
> repeat
> > this.
> > >
> > > This would create some interesting tickets for INFRA, but
> I won't
> > > waste their time with you either. Whether either of us has
> the
> > > authority to do such on ASF infrastructure is irrelevant,
> since
> > that
> > > is the only thing that can be argued here.  The ASL
> absolutely
> > allows
> > > people to innovate on their own with the code, so let's
> just
> > move the
> > > bits.
> > >
> > > Those who wish to innovate,
> > > https://github.com/driftx/cassandra/tree/cassandra-5.0 is
> now
> > open for
> > > business, PRs accepted. This will be maintained to track
> trunk
> > on the
> > > ASF servers.
> > >
> > > I guess this is the apache way.
> > >
> > >
> >
> -
> > > 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
> > >
> > >
> >
> > --
> > http://twitter.com/tjake
> >
> >
> >
> > -
> > To 

Re: Creating a branch for 5.0 …?

[Benedict Elliott Smith]

I'm not sure what you are referring to here, that vote said nothing about 
branching at beta.

The most recent vote on the topic anyway was for the Release Lifecycle process, 
which stipulates branching at GA.

https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle

We can vote to modify this document, or to make an exception, but I am aware of 
no other vote stipulating anything about the point at which we branch.


On 24/09/2020, 16:49, "Jake Luciani"  wrote:

> Today the community still has in force an explicit vote prohibiting thee
merge of this work.

You referred to an explicit vote here.  I assume that was the one you were
referring to?  Yes, the community should decide.
Call a vote if you think the community thinks we should continue the freeze
vs continuing to rely on beliefs about the community.

I'm simply pointing out the branching of 4.0 post beta was the plan of last
record.

Jake

On Thu, Sep 24, 2020 at 11:44 AM Benedict Elliott Smith 

wrote:

> The community does everything through discussion and consensus.  Does that
> include branching, or not?
>
> If there is no consensus, a vote is held.  Whether or not you consider the
> vote from 2018 still valid, you still need to seek the consent of the
> community for your action today.  Or is that not sacrosanct anymore?
>
>
> On 24/09/2020, 16:22, "Jake Luciani"  wrote:
>
> I'm sorry I see no issue with branching 4.0 as it was the thing we
> voted on
> back in 2018.  If you wish to extend the freeze you should call a new
> vote.
>
> On Thu, Sep 24, 2020 at 11:15 AM Benedict Elliott Smith <
> bened...@apache.org>
> wrote:
>
> > Nobody has any problem with an external repository being
> maintained.  Just
> > bear in mind the normal process will need to take place to merge to
> the ASF
> > repository, and that there may be feedback and review requests to
> address,
> > so merge order and diffs will probably change.
> >
> >
> > On 24/09/2020, 16:05, "Brandon Williams"  wrote:
> >
> > On Thu, Sep 24, 2020 at 9:55 AM Benedict Elliott Smith
> >  wrote:
> > >
> > > 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.
> >
> > Feel free to complain that I'm creating branches we intend to
> someday,
> > perhaps even in 2020, release.
> >
> > > I have deleted this branch, and will do so again if you repeat
> this.
> >
> > This would create some interesting tickets for INFRA, but I 
won't
> > waste their time with you either. Whether either of us has the
> > authority to do such on ASF infrastructure is irrelevant, since
> that
> > is the only thing that can be argued here.  The ASL absolutely
> allows
> > people to innovate on their own with the code, so let's just
> move the
> > bits.
> >
> > Those who wish to innovate,
> > https://github.com/driftx/cassandra/tree/cassandra-5.0 is now
> open for
> > business, PRs accepted. This will be maintained to track trunk
> on the
> > ASF servers.
> >
> > I guess this is the apache way.
> >
> >
>  -
> > 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
> >
> >
>
> --
> http://twitter.com/tjake
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

-- 
http://twitter.com/tjake



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Creating a branch for 5.0 …?

[Jake Luciani]

> Today the community still has in force an explicit vote prohibiting thee
merge of this work.

You referred to an explicit vote here.  I assume that was the one you were
referring to?  Yes, the community should decide.
Call a vote if you think the community thinks we should continue the freeze
vs continuing to rely on beliefs about the community.

I'm simply pointing out the branching of 4.0 post beta was the plan of last
record.

Jake

On Thu, Sep 24, 2020 at 11:44 AM Benedict Elliott Smith 
wrote:

> The community does everything through discussion and consensus.  Does that
> include branching, or not?
>
> If there is no consensus, a vote is held.  Whether or not you consider the
> vote from 2018 still valid, you still need to seek the consent of the
> community for your action today.  Or is that not sacrosanct anymore?
>
>
> On 24/09/2020, 16:22, "Jake Luciani"  wrote:
>
> I'm sorry I see no issue with branching 4.0 as it was the thing we
> voted on
> back in 2018.  If you wish to extend the freeze you should call a new
> vote.
>
> On Thu, Sep 24, 2020 at 11:15 AM Benedict Elliott Smith <
> bened...@apache.org>
> wrote:
>
> > Nobody has any problem with an external repository being
> maintained.  Just
> > bear in mind the normal process will need to take place to merge to
> the ASF
> > repository, and that there may be feedback and review requests to
> address,
> > so merge order and diffs will probably change.
> >
> >
> > On 24/09/2020, 16:05, "Brandon Williams"  wrote:
> >
> > On Thu, Sep 24, 2020 at 9:55 AM Benedict Elliott Smith
> >  wrote:
> > >
> > > 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.
> >
> > Feel free to complain that I'm creating branches we intend to
> someday,
> > perhaps even in 2020, release.
> >
> > > I have deleted this branch, and will do so again if you repeat
> this.
> >
> > This would create some interesting tickets for INFRA, but I won't
> > waste their time with you either. Whether either of us has the
> > authority to do such on ASF infrastructure is irrelevant, since
> that
> > is the only thing that can be argued here.  The ASL absolutely
> allows
> > people to innovate on their own with the code, so let's just
> move the
> > bits.
> >
> > Those who wish to innovate,
> > https://github.com/driftx/cassandra/tree/cassandra-5.0 is now
> open for
> > business, PRs accepted. This will be maintained to track trunk
> on the
> > ASF servers.
> >
> > I guess this is the apache way.
> >
> >
>  -
> > 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
> >
> >
>
> --
> http://twitter.com/tjake
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

-- 
http://twitter.com/tjake

Re: Creating a branch for 5.0 …?

[Jordan West]

https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle was
voted on after and under GA states: "A new branch is created for the
release with the new major version, limiting any new feature addition to
the new release branch, with new feature development will continue to
happen only on trunk."

Jordan


On Thu, Sep 24, 2020 at 8:12 AM Jake Luciani  wrote:

> >  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.
>
> Actually, the vote was defined to hold until beta release:
>
>
> https://lists.apache.org/thread.html/5ee66f3986bf8308912c216bd1b5f9aea35443626db9f92cdca4d7b9%40%3Cdev.cassandra.apache.org%3E
>
> -Jake
>
>
> On Thu, Sep 24, 2020 at 11:05 AM Brandon Williams 
> wrote:
>
> > On Thu, Sep 24, 2020 at 9:55 AM Benedict Elliott Smith
> >  wrote:
> > >
> > > 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.
> >
> > Feel free to complain that I'm creating branches we intend to someday,
> > perhaps even in 2020, release.
> >
> > > I have deleted this branch, and will do so again if you repeat this.
> >
> > This would create some interesting tickets for INFRA, but I won't
> > waste their time with you either. Whether either of us has the
> > authority to do such on ASF infrastructure is irrelevant, since that
> > is the only thing that can be argued here.  The ASL absolutely allows
> > people to innovate on their own with the code, so let's just move the
> > bits.
> >
> > Those who wish to innovate,
> > https://github.com/driftx/cassandra/tree/cassandra-5.0 is now open for
> > business, PRs accepted. This will be maintained to track trunk on the
> > ASF servers.
> >
> > I guess this is the apache way.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>
> --
> http://twitter.com/tjake
>

Re: Creating a branch for 5.0 …?

[Benedict Elliott Smith]

The community does everything through discussion and consensus.  Does that 
include branching, or not?

If there is no consensus, a vote is held.  Whether or not you consider the vote 
from 2018 still valid, you still need to seek the consent of the community for 
your action today.  Or is that not sacrosanct anymore?


On 24/09/2020, 16:22, "Jake Luciani"  wrote:

I'm sorry I see no issue with branching 4.0 as it was the thing we voted on
back in 2018.  If you wish to extend the freeze you should call a new vote.

On Thu, Sep 24, 2020 at 11:15 AM Benedict Elliott Smith 

wrote:

> Nobody has any problem with an external repository being maintained.  Just
> bear in mind the normal process will need to take place to merge to the 
ASF
> repository, and that there may be feedback and review requests to address,
> so merge order and diffs will probably change.
>
>
> On 24/09/2020, 16:05, "Brandon Williams"  wrote:
>
> On Thu, Sep 24, 2020 at 9:55 AM Benedict Elliott Smith
>  wrote:
> >
> > 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.
>
> Feel free to complain that I'm creating branches we intend to someday,
> perhaps even in 2020, release.
>
> > I have deleted this branch, and will do so again if you repeat this.
>
> This would create some interesting tickets for INFRA, but I won't
> waste their time with you either. Whether either of us has the
> authority to do such on ASF infrastructure is irrelevant, since that
> is the only thing that can be argued here.  The ASL absolutely allows
> people to innovate on their own with the code, so let's just move the
> bits.
>
> Those who wish to innovate,
> https://github.com/driftx/cassandra/tree/cassandra-5.0 is now open for
> business, PRs accepted. This will be maintained to track trunk on the
> ASF servers.
>
> I guess this is the apache way.
>
> -
> 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
>
>

-- 
http://twitter.com/tjake



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Creating a branch for 5.0 …?

[Jake Luciani]

I'm sorry I see no issue with branching 4.0 as it was the thing we voted on
back in 2018.  If you wish to extend the freeze you should call a new vote.

On Thu, Sep 24, 2020 at 11:15 AM Benedict Elliott Smith 
wrote:

> Nobody has any problem with an external repository being maintained.  Just
> bear in mind the normal process will need to take place to merge to the ASF
> repository, and that there may be feedback and review requests to address,
> so merge order and diffs will probably change.
>
>
> On 24/09/2020, 16:05, "Brandon Williams"  wrote:
>
> On Thu, Sep 24, 2020 at 9:55 AM Benedict Elliott Smith
>  wrote:
> >
> > 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.
>
> Feel free to complain that I'm creating branches we intend to someday,
> perhaps even in 2020, release.
>
> > I have deleted this branch, and will do so again if you repeat this.
>
> This would create some interesting tickets for INFRA, but I won't
> waste their time with you either. Whether either of us has the
> authority to do such on ASF infrastructure is irrelevant, since that
> is the only thing that can be argued here.  The ASL absolutely allows
> people to innovate on their own with the code, so let's just move the
> bits.
>
> Those who wish to innovate,
> https://github.com/driftx/cassandra/tree/cassandra-5.0 is now open for
> business, PRs accepted. This will be maintained to track trunk on the
> ASF servers.
>
> I guess this is the apache way.
>
> -
> 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
>
>

-- 
http://twitter.com/tjake

Re: Creating a branch for 5.0 …?

[Brandon Williams]

Indeed, it looks like there is no issue with branching now.

On Thu, Sep 24, 2020 at 10:12 AM Jake Luciani  wrote:
>
> >  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.
>
> Actually, the vote was defined to hold until beta release:
>
> https://lists.apache.org/thread.html/5ee66f3986bf8308912c216bd1b5f9aea35443626db9f92cdca4d7b9%40%3Cdev.cassandra.apache.org%3E
>
> -Jake
>
>
> On Thu, Sep 24, 2020 at 11:05 AM Brandon Williams  wrote:
>
> > On Thu, Sep 24, 2020 at 9:55 AM Benedict Elliott Smith
> >  wrote:
> > >
> > > 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.
> >
> > Feel free to complain that I'm creating branches we intend to someday,
> > perhaps even in 2020, release.
> >
> > > I have deleted this branch, and will do so again if you repeat this.
> >
> > This would create some interesting tickets for INFRA, but I won't
> > waste their time with you either. Whether either of us has the
> > authority to do such on ASF infrastructure is irrelevant, since that
> > is the only thing that can be argued here.  The ASL absolutely allows
> > people to innovate on their own with the code, so let's just move the
> > bits.
> >
> > Those who wish to innovate,
> > https://github.com/driftx/cassandra/tree/cassandra-5.0 is now open for
> > business, PRs accepted. This will be maintained to track trunk on the
> > ASF servers.
> >
> > I guess this is the apache way.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>
> --
> http://twitter.com/tjake

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Creating a branch for 5.0 …?

[Benedict Elliott Smith]

Nobody has any problem with an external repository being maintained.  Just bear 
in mind the normal process will need to take place to merge to the ASF 
repository, and that there may be feedback and review requests to address, so 
merge order and diffs will probably change.


On 24/09/2020, 16:05, "Brandon Williams"  wrote:

On Thu, Sep 24, 2020 at 9:55 AM Benedict Elliott Smith
 wrote:
>
> 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.

Feel free to complain that I'm creating branches we intend to someday,
perhaps even in 2020, release.

> I have deleted this branch, and will do so again if you repeat this.

This would create some interesting tickets for INFRA, but I won't
waste their time with you either. Whether either of us has the
authority to do such on ASF infrastructure is irrelevant, since that
is the only thing that can be argued here.  The ASL absolutely allows
people to innovate on their own with the code, so let's just move the
bits.

Those who wish to innovate,
https://github.com/driftx/cassandra/tree/cassandra-5.0 is now open for
business, PRs accepted. This will be maintained to track trunk on the
ASF servers.

I guess this is the apache way.

-
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

Re: Creating a branch for 5.0 …?

[Jake Luciani]

>  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.

Actually, the vote was defined to hold until beta release:

https://lists.apache.org/thread.html/5ee66f3986bf8308912c216bd1b5f9aea35443626db9f92cdca4d7b9%40%3Cdev.cassandra.apache.org%3E

-Jake


On Thu, Sep 24, 2020 at 11:05 AM Brandon Williams  wrote:

> On Thu, Sep 24, 2020 at 9:55 AM Benedict Elliott Smith
>  wrote:
> >
> > 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.
>
> Feel free to complain that I'm creating branches we intend to someday,
> perhaps even in 2020, release.
>
> > I have deleted this branch, and will do so again if you repeat this.
>
> This would create some interesting tickets for INFRA, but I won't
> waste their time with you either. Whether either of us has the
> authority to do such on ASF infrastructure is irrelevant, since that
> is the only thing that can be argued here.  The ASL absolutely allows
> people to innovate on their own with the code, so let's just move the
> bits.
>
> Those who wish to innovate,
> https://github.com/driftx/cassandra/tree/cassandra-5.0 is now open for
> business, PRs accepted. This will be maintained to track trunk on the
> ASF servers.
>
> I guess this is the apache way.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

-- 
http://twitter.com/tjake

Re: Creating a branch for 5.0 …?

[Brandon Williams]

On Thu, Sep 24, 2020 at 9:55 AM Benedict Elliott Smith
 wrote:
>
> 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.

Feel free to complain that I'm creating branches we intend to someday,
perhaps even in 2020, release.

> I have deleted this branch, and will do so again if you repeat this.

This would create some interesting tickets for INFRA, but I won't
waste their time with you either. Whether either of us has the
authority to do such on ASF infrastructure is irrelevant, since that
is the only thing that can be argued here.  The ASL absolutely allows
people to innovate on their own with the code, so let's just move the
bits.

Those who wish to innovate,
https://github.com/driftx/cassandra/tree/cassandra-5.0 is now open for
business, PRs accepted. This will be maintained to track trunk on the
ASF servers.

I guess this is the apache way.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Creating a branch for 5.0 …?

[Oleksandr Petrov]

> 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  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  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 
> 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, 

Re: Creating a branch for 5.0 …?

[Benedict Elliott Smith]

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"  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  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  
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 
 >>> wrote:
> >>
> >> I know. I recognise that is a frustrating aspect of this discussion. 
It is
> >> something hard to move on.
> >>
> >> So how 

Re: Creating a branch for 5.0 …?

[Brandon Williams]

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  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  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 
> >>  >>> 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"  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 

Re: Creating a branch for 5.0 …?

[Dinesh Joshi]

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  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 >> 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"  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

Re: Creating a branch for 5.0 …?

[Joshua McKenzie]

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  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"  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
>

Re: Creating a branch for 5.0 …?

[Benedict Elliott Smith]

> 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"  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

Re: Creating a branch for 5.0 …?

[Mick Semb Wever]

> 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.

Re: Creating a branch for 5.0 …?

[Benedict Elliott Smith]

> But I would suggest that we are more productive when
> raising and discussing concrete examples and specific patches

You make a good point.  Can you provide some concrete examples of your own? 
Ironically, this entire proposal so far rests on hypothetical lost 
contributions by hypothetical companies and individuals.

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.


On 15/09/2020, 22:00, "Mick Semb Wever"  wrote:

We know we are turning away more and more contributions and new potential
> dev community with our 4.0 feature freeze, and it has been going on for a
> while now.
>
> I would like to suggest we create a cassandra-5.0 branch where we can
> start to queue up all reviewed and ready-to-go post-4.0 commits.
>




I am going to take a stab at closing the loop on this thread.

So far no one has indicated any desire to maintain a cassandra-5.0 branch.
While people have expressed concerns about what it would mean for the
release date and quality of 4.0-rc. As a community we don't have an answer
to these concerns. But I would suggest that we are more productive when
raising and discussing concrete examples and specific patches where-ever we
see a potential impact, like we have done with the messaging system
rewrite, those bugs that slipped 4.0-alpha, and the byte array backed cells
rewrite.

Since a number of people have asked off-list for more detail and
clarification on how the cassandra-5.0 branch would work in a way that
doesn't require community voting/approval, and incase anyone does step up
to take it on, the following is a more detailed writeup to the workflow i
was thinking…

1. Patches are reviewed by two Committers on tickets that are marked `4.x`.
   a. These patches are not relevant for any current versions (2.2, 3.0,
3.11, 4.0)
   b. If these patches require a CEP, then they must have first passed the
CEP.
   c. These are patches from new contributors that we would otherwise lose.
   d. Reviewers are not retreating from 4.0-rc efforts.

2. When successfully reviewed, the single commit that makes the patch is
committed to the cassandra-5.0 branch.
3. The ticket is transitioned to "Ready to Commit", and a comment added
that the patch now resides in the cassandra-5.0 branch.

4. At regular intervals, the cassandra-5.0 maintainers rebase (and rerere)
the branch off trunk.
   a. ci-cassandra.a.o runs CI on the cassandra-5.0

5. When 4.0 is branched and the feature freeze is announced over, an email
to the dev ML is sent that the patches parked in the cassandra-5.0 will
soon be committed.
   a. There needs to be a balance here between appreciating late-reviewers
who were busy Doing The Right Thing being given a chance to provide
feedback, and that two trusted committers have already signed off on the
patch.

6. The cassandra-5.0 branch is fast-forward merged into trunk (minus any
commits that have had reviews re-opened on them).



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Creating a branch for 5.0 …?

[Brandon Williams]

On Tue, Sep 15, 2020 at 4:00 PM Mick Semb Wever  wrote:
> So far no one has indicated any desire to maintain a cassandra-5.0 branch.

Sorry, I'm just catching up from vacation.  I'd be glad to help with this.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Creating a branch for 5.0 …?

[Mick Semb Wever]

We know we are turning away more and more contributions and new potential
> dev community with our 4.0 feature freeze, and it has been going on for a
> while now.
>
> I would like to suggest we create a cassandra-5.0 branch where we can
> start to queue up all reviewed and ready-to-go post-4.0 commits.
>




I am going to take a stab at closing the loop on this thread.

So far no one has indicated any desire to maintain a cassandra-5.0 branch.
While people have expressed concerns about what it would mean for the
release date and quality of 4.0-rc. As a community we don't have an answer
to these concerns. But I would suggest that we are more productive when
raising and discussing concrete examples and specific patches where-ever we
see a potential impact, like we have done with the messaging system
rewrite, those bugs that slipped 4.0-alpha, and the byte array backed cells
rewrite.

Since a number of people have asked off-list for more detail and
clarification on how the cassandra-5.0 branch would work in a way that
doesn't require community voting/approval, and incase anyone does step up
to take it on, the following is a more detailed writeup to the workflow i
was thinking…

1. Patches are reviewed by two Committers on tickets that are marked `4.x`.
   a. These patches are not relevant for any current versions (2.2, 3.0,
3.11, 4.0)
   b. If these patches require a CEP, then they must have first passed the
CEP.
   c. These are patches from new contributors that we would otherwise lose.
   d. Reviewers are not retreating from 4.0-rc efforts.

2. When successfully reviewed, the single commit that makes the patch is
committed to the cassandra-5.0 branch.
3. The ticket is transitioned to "Ready to Commit", and a comment added
that the patch now resides in the cassandra-5.0 branch.

4. At regular intervals, the cassandra-5.0 maintainers rebase (and rerere)
the branch off trunk.
   a. ci-cassandra.a.o runs CI on the cassandra-5.0

5. When 4.0 is branched and the feature freeze is announced over, an email
to the dev ML is sent that the patches parked in the cassandra-5.0 will
soon be committed.
   a. There needs to be a balance here between appreciating late-reviewers
who were busy Doing The Right Thing being given a chance to provide
feedback, and that two trusted committers have already signed off on the
patch.

6. The cassandra-5.0 branch is fast-forward merged into trunk (minus any
commits that have had reviews re-opened on them).

Re: Creating a branch for 5.0 …?

[Joshua McKenzie]

>
> 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 
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
> 

Re: Creating a branch for 5.0 …?

[Benedict Elliott Smith]

> 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"  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  wrote:

> On Fri, Sep 11, 2020 at 9:18 AM Joshua McKenzie 
> 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  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/
> 

Re: Creating a branch for 5.0 …?

[Joshua McKenzie]

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  wrote:

> On Fri, Sep 11, 2020 at 9:18 AM Joshua McKenzie 
> 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  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  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"  wrote:
>
> For significant new 

Re: Creating a branch for 5.0 …?

[Jordan West]

On Fri, Sep 11, 2020 at 9:18 AM Joshua McKenzie 
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  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  > 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"  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
> > 

Re: Creating a branch for 5.0 …?

[Joshua McKenzie]

it seems unlikely this conversation will be any different than the one we
had on the same topic 11 weeks ago

The big difference to me is whether the turning point on the conversation
is the extra work required by people working on 4.0 to merge up to a new
trunk or if the turning point is on a desire to enforce a certain focus of
work on project contributions. I thought it was the former; seems like it's
the latter.



On Fri, Sep 11, 2020 at 12:10 PM, Jordan West  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  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"  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 

Re: Creating a branch for 5.0 …?

[Jordan West]

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 
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"  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
> 

Re: Creating a branch for 5.0 …?

[Benedict Elliott Smith]

> 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"  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 

Re: Creating a branch for 5.0 …?

[Mick Semb Wever]

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.

Re: Creating a branch for 5.0 …?

[Benedict Elliott Smith]

As I said before

> The more significant cost to the project is distracting contributors focused 
> on 4.0

This a conversation we keep coming back to, so I will highlight this phrase for 
future repetition: Work does not happen in a vacuum. The whole community bears 
a cost when new work is integrated.

I am personally not interested in further breaking the backs of those 
individuals who have been working to exhaustion for some time to fix historical 
issues, so that we can accommodate some mythical organisation that has never 
yet contributed, and only won't because they don't care to participate in the 
project's goals.  If they really do want to get involved, they can either wait 
until the project is ready or get involved in shipping 4.0.


On 11/09/2020, 10:53, "Benjamin Lerer"  wrote:

>
> People might be itching to get out, particularly those who are unlikely to
> be harmed, but most agree to stay put for the benefit of the community.
>

The freeze has been there for quite a while now and as far as I can see the
goal of all those working on C* right now is to have 4.0 out. Will there
really be a move of resources knowing that the new work will never be
released if 4.0 is not?

On one side we have the fear to delay 4.0 on the other the fear to lose
people who would want to contribute but are not interested in contributing
to testing.

I trust that there are people or companies interested in contributing but
not in testing. Amazon if I recall correctly mentioned that they wanted to
contribute and are probably not so much interested in testing 4.0. I
imagine that it might be the same for some other vendors.
As a developer looking to contribute to an open source project, I would
probably avoid projects that have been frozen for more than a year.

Allowing people with diverse goals to get involved can only help the
project in my opinion. As once you have been involved you will want your
contribution to be released.

As far as I am concerned a new branch will not change my main goal which is
to have 4.0 out of the door.


On Fri, Sep 11, 2020 at 11:03 AM Benedict Elliott Smith 

wrote:

> This is a social enterprise, and we are all able to enter into a social
> contract/convention.  This doesn't prevent someone from breaking the
> convention, or not agreeing to it, of course, but this entails social
> costs.  This is exactly how the feature-freeze has worked until now,
> curtailing development - not just merging.
>
> 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.
>
> I personally do not condone a total relaxation of the freeze, even to a
> volunteer-maintained repository.  We can perhaps think of the freeze like 
a
> pandemic lockdown: if we relax before we have the correct measures in
> place, much of the good work will be undone.  People might be itching to
> get out, particularly those who are unlikely to be harmed, but most agree
> to stay put for the benefit of the community.  However, the community 
might
> together agree to a partial-relaxation if it can be done safely.
>
>
>
>
> On 11/09/2020, 04:09, "Jeff Jirsa"  wrote:
> > On Sep 10, 2020, at 2:42 PM, Benedict Elliott Smith <
> bened...@apache.org> wrote:
> >
> > 
> >>
> >> As I understand Sankalp's primary (and quite reasonable) argument
> the last time we discussed this
> >
> > 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 - by how much,
> who knows?
> >
> > Of course, the new features will also get less attention than they
> should.  So it's a lose-lose in that respect.
> >
> > I think if we are to consider this, any ticket or project for 5.0
> should be subject to a consensus vote before work begins.  Work that a
> contributor - focused on the more urgent and less rewarding job of 
shipping
> 4.0 - would participate in can be deferred.  Uncontentious work, or work
> where all relevant contributors are free to participate, can make 
progress.
>
> I have no opinion on branching, but 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.
> 

Re: Creating a branch for 5.0 …?

[Benjamin Lerer]

>
> People might be itching to get out, particularly those who are unlikely to
> be harmed, but most agree to stay put for the benefit of the community.
>

The freeze has been there for quite a while now and as far as I can see the
goal of all those working on C* right now is to have 4.0 out. Will there
really be a move of resources knowing that the new work will never be
released if 4.0 is not?

On one side we have the fear to delay 4.0 on the other the fear to lose
people who would want to contribute but are not interested in contributing
to testing.

I trust that there are people or companies interested in contributing but
not in testing. Amazon if I recall correctly mentioned that they wanted to
contribute and are probably not so much interested in testing 4.0. I
imagine that it might be the same for some other vendors.
As a developer looking to contribute to an open source project, I would
probably avoid projects that have been frozen for more than a year.

Allowing people with diverse goals to get involved can only help the
project in my opinion. As once you have been involved you will want your
contribution to be released.

As far as I am concerned a new branch will not change my main goal which is
to have 4.0 out of the door.


On Fri, Sep 11, 2020 at 11:03 AM Benedict Elliott Smith 
wrote:

> This is a social enterprise, and we are all able to enter into a social
> contract/convention.  This doesn't prevent someone from breaking the
> convention, or not agreeing to it, of course, but this entails social
> costs.  This is exactly how the feature-freeze has worked until now,
> curtailing development - not just merging.
>
> 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.
>
> I personally do not condone a total relaxation of the freeze, even to a
> volunteer-maintained repository.  We can perhaps think of the freeze like a
> pandemic lockdown: if we relax before we have the correct measures in
> place, much of the good work will be undone.  People might be itching to
> get out, particularly those who are unlikely to be harmed, but most agree
> to stay put for the benefit of the community.  However, the community might
> together agree to a partial-relaxation if it can be done safely.
>
>
>
>
> On 11/09/2020, 04:09, "Jeff Jirsa"  wrote:
> > On Sep 10, 2020, at 2:42 PM, Benedict Elliott Smith <
> bened...@apache.org> wrote:
> >
> > 
> >>
> >> As I understand Sankalp's primary (and quite reasonable) argument
> the last time we discussed this
> >
> > 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 - by how much,
> who knows?
> >
> > Of course, the new features will also get less attention than they
> should.  So it's a lose-lose in that respect.
> >
> > I think if we are to consider this, any ticket or project for 5.0
> should be subject to a consensus vote before work begins.  Work that a
> contributor - focused on the more urgent and less rewarding job of shipping
> 4.0 - would participate in can be deferred.  Uncontentious work, or work
> where all relevant contributors are free to participate, can make progress.
>
> I have no opinion on branching, but 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.
> -
> 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
>
>

Re: Creating a branch for 5.0 …?

[Benedict Elliott Smith]

This is a social enterprise, and we are all able to enter into a social 
contract/convention.  This doesn't prevent someone from breaking the 
convention, or not agreeing to it, of course, but this entails social costs.  
This is exactly how the feature-freeze has worked until now, curtailing 
development - not just merging.

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.

I personally do not condone a total relaxation of the freeze, even to a 
volunteer-maintained repository.  We can perhaps think of the freeze like a 
pandemic lockdown: if we relax before we have the correct measures in place, 
much of the good work will be undone.  People might be itching to get out, 
particularly those who are unlikely to be harmed, but most agree to stay put 
for the benefit of the community.  However, the community might together agree 
to a partial-relaxation if it can be done safely.




On 11/09/2020, 04:09, "Jeff Jirsa"  wrote:
> On Sep 10, 2020, at 2:42 PM, Benedict Elliott Smith  
wrote:
> 
> 
>> 
>> As I understand Sankalp's primary (and quite reasonable) argument the 
last time we discussed this
> 
> 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 - by how much, who knows?
> 
> Of course, the new features will also get less attention than they 
should.  So it's a lose-lose in that respect.
> 
> I think if we are to consider this, any ticket or project for 5.0 should 
be subject to a consensus vote before work begins.  Work that a contributor - 
focused on the more urgent and less rewarding job of shipping 4.0 - would 
participate in can be deferred.  Uncontentious work, or work where all relevant 
contributors are free to participate, can make progress.

I have no opinion on branching, but 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. 
-
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

Re: Creating a branch for 5.0 …?

[Stefan Miklosovic]

I second David. I think I can speak up here as I perfectly fit into
the bucket of "new people trying to contribute".

While it is true that reviews tend to take a long time I am perfectly
happy with people who eventually look at them. It is understandable
that there is a lot of going on and a committer / more experienced
people do not have time to give a feedback immediately but as long as
it is not forgotten completely (which has never happened to me), to me
personally it does not matter too much how "fast" something is
reviewed and merged even though I would be delighted if my changes are
reviewed and merged faster (who would not not be, right?)

I do not think that making yet another branch would make any
significant difference, it can always be done against trunk and it
would be harder to merge back as there might be a lot of conflicts etc
... Anyway, I am trying to go over tickets which are fixing and
improving upcoming 4.0 and they are retrofitted into older branches if
applicable. It is a very nice compromise. It gives signals to folks
like "sure, we look into it, but if it fixes things in 4.0, it will be
looked at even faster", so it motivates people to primarily focus on
4.0 which directly benefits the project to release 4.0 sooner.

There is also an argument in this thread that having cassandra-5.0
would leave the burden of rebasing / fixing conflicts to respective
contributors, quoting: "A cassandra-5.0 branch in-tree where the
burden of maintenance would fall on people using the branch seems to
mitigate that concern.". To be honest, I find myself preparing the
branch for committers / reviewers perfectly fine and it is the minimum
I can do so they do not have to - it is just a basic courtesy to
prepare my work in such a way that it is reviewed comfortably and it
can go straight in. I am even semi regularly ensuring that my open
branches are on-par with the trunk every other day so once a comitter
takes a look, everything is in place. I do not know if I am an
exception but this is just natural process to me.

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.



On Thu, 10 Sep 2020 at 22:25, David Capwell  wrote:
>
> >
> > The effort of the cassandra-5.0 branch maintenance: rebasing (git rerere);
> > is just upon those that wish to take it on
>
>
> I don't follow.  If a bug fix goes into 4.0 do we not need to sync this
> with 5.0, if so then this would be the 5th branch to keep in-sync, and if
> the feature freeze is lifted then this branch may diverge making it harder
> to apply the patch to.
>
> Tickets that have been reviewed and are (aside from the feature-freeze)
> > ready to be committed, can be committed to the `cassandra-5.0` branch
>
>
> Is there such a backlog of tickets that have been reviewed and not going
> into 4.0.0?  What I see are ideas and things punted from review, so it
> would be good to see what this backlog is and how large.
>
> My main fear is reviews of new tickets.  A complaint I have heard multiple
> times from several people is that not enough people are reviewing and
> reviews take a long time (number of reviewers is small and their backlog
> keeps growing).  If we open up reviews for non 4.0.0 work then my fear is
> that even less review time will be allocated to 4.0.0 work.
>
> - who would be willing to help maintain this cassandra-5.0 branch?
>
>
> I do not have the time so I will not be able to help with 5.0 work.
>
>  - should it be kept external in a GH fork? Or would you rather have the
> > branch in our main git repository?
>
>
> To me GH fork is the same as not committed and not reviewed.  If a fork
> would help the community then I am ok with it, but I don't see it as ready
> to commit.
>
> On Thu, Sep 10, 2020 at 12:58 PM Mick Semb Wever  wrote:
>
> > We know we are turning away more and more contributions and new potential
> > dev community with our 4.0 feature freeze, and it has been going on for a
> > while now.
> >
> > I would like to suggest we create a cassandra-5.0 branch where we can start
> > to queue up all reviewed and ready-to-go post-4.0 commits.
> >
> > This is not to distract from getting 4.0 out, where our primary focus is,
> > but as a stop-gap in losing those contributions. The effort of the
> > cassandra-5.0 branch maintenance: rebasing (git rerere); is just upon those
> > that wish to take it on, and the branch can be located in whatever GH
> > fork those
> > individuals wish to keep it in. Tickets that have been reviewed and are
> > (aside from the feature-freeze) ready to be committed, can be committed to
> > the `cassandra-5.0` branch while their tickets remain in "Ready to Commit"
> > status. The goal of this effort would be, a) we are giving the signal to
> > contributors to get involved again (even while our primary focus in on
> > 

Re: Creating a branch for 5.0 …?

[Caleb Rackliffe]

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.

> On Sep 10, 2020, at 11:39 PM, Dinesh Joshi  wrote:
> 
> 
>> 
>> On Sep 10, 2020, at 2:10 PM, Joshua McKenzie  wrote:
>> 
>> I can offer my anecdata: I know of two major enterprises as well as have
>> had two interviewees unsolicited bring up to me that they have walked away
>> from or bounced off the project due to the feature freeze / branching
>> strategy. I may be the anomaly given the volume of people in the ecosystem
>> I interact with, but I assume it's more than just the ones I've seen.
> 
> Did these folks bring this issue up with dev@ or private@ before deciding to 
> go in a different direction?
> 
> Dinesh
> -
> 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

Re: Creating a branch for 5.0 …?

[Dinesh Joshi]

> On Sep 10, 2020, at 2:10 PM, Joshua McKenzie  wrote:
> 
> I can offer my anecdata: I know of two major enterprises as well as have
> had two interviewees unsolicited bring up to me that they have walked away
> from or bounced off the project due to the feature freeze / branching
> strategy. I may be the anomaly given the volume of people in the ecosystem
> I interact with, but I assume it's more than just the ones I've seen.

Did these folks bring this issue up with dev@ or private@ before deciding to go 
in a different direction?

Dinesh
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Creating a branch for 5.0 …?

[Jeff Jirsa]

> On Sep 10, 2020, at 2:42 PM, Benedict Elliott Smith  
> wrote:
> 
> 
>> 
>> As I understand Sankalp's primary (and quite reasonable) argument the last 
>> time we discussed this
> 
> 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 - by how much, who knows?
> 
> Of course, the new features will also get less attention than they should.  
> So it's a lose-lose in that respect.
> 
> I think if we are to consider this, any ticket or project for 5.0 should be 
> subject to a consensus vote before work begins.  Work that a contributor - 
> focused on the more urgent and less rewarding job of shipping 4.0 - would 
> participate in can be deferred.  Uncontentious work, or work where all 
> relevant contributors are free to participate, can make progress.

I have no opinion on branching, but 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. 
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Creating a branch for 5.0 …?

[Mick Semb Wever]

Replies inline, though I think Josh answered everything well enough already.

> The effort of the cassandra-5.0 branch maintenance: rebasing (git rerere);
> > is just upon those that wish to take it on
>
>
> I don't follow.  If a bug fix goes into 4.0 do we not need to sync this
> with 5.0, if so then this would be the 5th branch to keep in-sync, and if
> the feature freeze is lifted then this branch may diverge making it harder
> to apply the patch to.
>


We are talking about things that would only go into a 5.0 branch.
As soon as the feature freeze is lifted, then all the commits in the 5.0
branch are rolled onto trunk (i.e. a fast-forward merge).

The branch is regularly rebased off trunk. That work is on those willing to
take on the endeavour, not the community.


Tickets that have been reviewed and are (aside from the feature-freeze)
> > ready to be committed, can be committed to the `cassandra-5.0` branch
>
>
> Is there such a backlog of tickets that have been reviewed and not going
> into 4.0.0?  What I see are ideas and things punted from review, so it
> would be good to see what this backlog is and how large.
>


You're correct, we are talking about a backlog of tickets that has not
materialised. We have enough signals to know why they are not
materialising. We can't say what will materialise, hopefully folk will come
back.  That's why we can't ask for "the backlog" in advance.

My main fear is reviews of new tickets.  A complaint I have heard multiple
> times from several people is that not enough people are reviewing and
> reviews take a long time (number of reviewers is small and their backlog
> keeps growing).



Absolutely agree with you David. Lack of reviewers, and focusing reviewers
on 4.0, is crucial. I'm pretty sure everyone agrees.
But new contributions is community health and growth, and there's genuine
concerns we're losing them. And we *are* seeing it.



> To me GH fork is the same as not committed and not reviewed.  If a fork
> would help the community then I am ok with it, but I don't see it as ready
> to commit.
>


The feature freeze is about what can and can't go into trunk (and us not
branching yet cassandra-4.0).

There's no restrictions around reviewing tickets and transitioning or
commenting them as "ready to commit" on the presumption the reviewer is one
of those bearing the burden of the cassandra-5.0 branch maintenance and
ensuring the fast-forward merge of it to a post-4.0 trunk is of the same
standard expected of every commit pushed.

If the community wanted to extend the feature freeze to blocking jira
transitions to "ready to commit" for post-4.0 work, those reviewers could
just do that book-keeping themselves. No community vote or consensus is
required for those willing to do this, because it can be done externally.
So I'm thinking going into such process formalities distracts us from
having the real conversation… who's willing to do it? and if you are, do
you believe you can do so without taking any (review) time away from 4.0
efforts? and is it clearly understood that your additional effort is
restricted to contributions from new significant contributors that we feel
we would otherwise lose?

I know folk will have strong opinions on this, that's no surprise, it's
meant as a discussion opener.

Re: Creating a branch for 5.0 …?

[Benedict Elliott Smith]

> As I understand Sankalp's primary (and quite reasonable) argument the last 
> time we discussed this

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 - by how much, who knows?

Of course, the new features will also get less attention than they should.  So 
it's a lose-lose in that respect.

I think if we are to consider this, any ticket or project for 5.0 should be 
subject to a consensus vote before work begins.  Work that a contributor - 
focused on the more urgent and less rewarding job of shipping 4.0 - would 
participate in can be deferred.  Uncontentious work, or work where all relevant 
contributors are free to participate, can make progress.


On 10/09/2020, 22:10, "Joshua McKenzie"  wrote:

I can offer my anecdata: I know of two major enterprises as well as have
had two interviewees unsolicited bring up to me that they have walked away
from or bounced off the project due to the feature freeze / branching
strategy. I may be the anomaly given the volume of people in the ecosystem
I interact with, but I assume it's more than just the ones I've seen.

Mick, correct me if I'm wrong but the merge path for a bugfix to 2.1 that
applies up to 4.0, as an example, would look like:

2.1 → 3.0 → 3.11 → trunk

With no extra work required and an accumulation of a backlog of things on
trunk not on the cassandra-5.0 branch.

If someone else were working on something in the cassandra-5.0 branch,
they'd need to rebase/rerere the 5.0 branch on trunk before making whatever
changes. In effect this would move the burden from merge resolution to
whomever was choosing to work on the cassandra-5.0 branch instead of
maintainers working on 4.0.

> Is there such a backlog of tickets that have been reviewed and not going
into 4.0.0?
Chicken or egg debate right? Nobody is going to review code for post 4.0
right now if there's nowhere to put it since it'll just atrophy and need
constant rebasing and thus re-review. Or it ends up in a fork somewhere.

As I understand Sankalp's primary (and quite reasonable) argument the last
time we discussed this, the concern was the extra work needed to merge
forward for people working on 4.0. A cassandra-5.0 branch in-tree where the
burden of maintenance would fall on people using the branch seems to
mitigate that concern.

Also, when 4.0 GA'ed wouldn't we just trunk become a 4.0 branch and then
cassandra-5.0 become trunk?




On Thu, Sep 10, 2020 at 4:32 PM, Benedict Elliott Smith  wrote:

> We know we are turning away more and more contributions
>
> Do we? I haven't been aware of much of this occurring at all.
>
> On 10/09/2020, 20:58, "Mick Semb Wever"  wrote:
>
> We know we are turning away more and more contributions and new potential
> dev community with our 4.0 feature freeze, and it has been going on for a
> while now.
>
> I would like to suggest we create a cassandra-5.0 branch where we can
> start to queue up all reviewed and ready-to-go post-4.0 commits.
>
> This is not to distract from getting 4.0 out, where our primary focus is,
> but as a stop-gap in losing those contributions. The effort of the
> cassandra-5.0 branch maintenance: rebasing (git rerere); is just upon 
those
> that wish to take it on, and the branch can be located in whatever GH fork
> those
> individuals wish to keep it in. Tickets that have been reviewed and are
> (aside from the feature-freeze) ready to be committed, can be committed to
> the `cassandra-5.0` branch while their tickets remain in "Ready to Commit"
> status. The goal of this effort would be, a) we are giving the signal to
> contributors to get involved again (even while our primary focus in on
> stabilisation and testing efforts), and b) maintaining CI status on the
> sequence of commits that are ready to go into trunk post 4.0-rc.
>
> My questions are…
> - who would be willing to help maintain this cassandra-5.0 branch?
> - should it be kept external in a GH fork? Or would you rather have the
> branch in our main git repository?
>
> regards,
> Mick
>
> - 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

Re: Creating a branch for 5.0 …?

[Joshua McKenzie]

I can offer my anecdata: I know of two major enterprises as well as have
had two interviewees unsolicited bring up to me that they have walked away
from or bounced off the project due to the feature freeze / branching
strategy. I may be the anomaly given the volume of people in the ecosystem
I interact with, but I assume it's more than just the ones I've seen.

Mick, correct me if I'm wrong but the merge path for a bugfix to 2.1 that
applies up to 4.0, as an example, would look like:

2.1 → 3.0 → 3.11 → trunk

With no extra work required and an accumulation of a backlog of things on
trunk not on the cassandra-5.0 branch.

If someone else were working on something in the cassandra-5.0 branch,
they'd need to rebase/rerere the 5.0 branch on trunk before making whatever
changes. In effect this would move the burden from merge resolution to
whomever was choosing to work on the cassandra-5.0 branch instead of
maintainers working on 4.0.

> Is there such a backlog of tickets that have been reviewed and not going
into 4.0.0?
Chicken or egg debate right? Nobody is going to review code for post 4.0
right now if there's nowhere to put it since it'll just atrophy and need
constant rebasing and thus re-review. Or it ends up in a fork somewhere.

As I understand Sankalp's primary (and quite reasonable) argument the last
time we discussed this, the concern was the extra work needed to merge
forward for people working on 4.0. A cassandra-5.0 branch in-tree where the
burden of maintenance would fall on people using the branch seems to
mitigate that concern.

Also, when 4.0 GA'ed wouldn't we just trunk become a 4.0 branch and then
cassandra-5.0 become trunk?




On Thu, Sep 10, 2020 at 4:32 PM, Benedict Elliott Smith  wrote:

> We know we are turning away more and more contributions
>
> Do we? I haven't been aware of much of this occurring at all.
>
> On 10/09/2020, 20:58, "Mick Semb Wever"  wrote:
>
> We know we are turning away more and more contributions and new potential
> dev community with our 4.0 feature freeze, and it has been going on for a
> while now.
>
> I would like to suggest we create a cassandra-5.0 branch where we can
> start to queue up all reviewed and ready-to-go post-4.0 commits.
>
> This is not to distract from getting 4.0 out, where our primary focus is,
> but as a stop-gap in losing those contributions. The effort of the
> cassandra-5.0 branch maintenance: rebasing (git rerere); is just upon those
> that wish to take it on, and the branch can be located in whatever GH fork
> those
> individuals wish to keep it in. Tickets that have been reviewed and are
> (aside from the feature-freeze) ready to be committed, can be committed to
> the `cassandra-5.0` branch while their tickets remain in "Ready to Commit"
> status. The goal of this effort would be, a) we are giving the signal to
> contributors to get involved again (even while our primary focus in on
> stabilisation and testing efforts), and b) maintaining CI status on the
> sequence of commits that are ready to go into trunk post 4.0-rc.
>
> My questions are…
> - who would be willing to help maintain this cassandra-5.0 branch?
> - should it be kept external in a GH fork? Or would you rather have the
> branch in our main git repository?
>
> regards,
> Mick
>
> - To
> unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional
> commands, e-mail: dev-h...@cassandra.apache.org
>

Re: Creating a branch for 5.0 …?

[Benedict Elliott Smith]

> We know we are turning away more and more contributions

Do we? I haven't been aware of much of this occurring at all. 

On 10/09/2020, 20:58, "Mick Semb Wever"  wrote:

We know we are turning away more and more contributions and new potential
dev community with our 4.0 feature freeze, and it has been going on for a
while now.

I would like to suggest we create a cassandra-5.0 branch where we can start
to queue up all reviewed and ready-to-go post-4.0 commits.

This is not to distract from getting 4.0 out, where our primary focus is,
but as a stop-gap in losing those contributions. The effort of the
cassandra-5.0 branch maintenance: rebasing (git rerere); is just upon those
that wish to take it on, and the branch can be located in whatever GH
fork those
individuals wish to keep it in. Tickets that have been reviewed and are
(aside from the feature-freeze) ready to be committed, can be committed to
the `cassandra-5.0` branch while their tickets remain in "Ready to Commit"
status. The goal of this effort would be, a) we are giving the signal to
contributors to get involved again (even while our primary focus in on
stabilisation and testing efforts), and b) maintaining CI status on the
sequence of commits that are ready to go into trunk post 4.0-rc.

My questions are…
 - who would be willing to help maintain this cassandra-5.0 branch?
 - should it be kept external in a GH fork? Or would you rather have the
branch in our main git repository?

regards,
Mick



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Creating a branch for 5.0 …?

[David Capwell]

>
> The effort of the cassandra-5.0 branch maintenance: rebasing (git rerere);
> is just upon those that wish to take it on


I don't follow.  If a bug fix goes into 4.0 do we not need to sync this
with 5.0, if so then this would be the 5th branch to keep in-sync, and if
the feature freeze is lifted then this branch may diverge making it harder
to apply the patch to.

Tickets that have been reviewed and are (aside from the feature-freeze)
> ready to be committed, can be committed to the `cassandra-5.0` branch


Is there such a backlog of tickets that have been reviewed and not going
into 4.0.0?  What I see are ideas and things punted from review, so it
would be good to see what this backlog is and how large.

My main fear is reviews of new tickets.  A complaint I have heard multiple
times from several people is that not enough people are reviewing and
reviews take a long time (number of reviewers is small and their backlog
keeps growing).  If we open up reviews for non 4.0.0 work then my fear is
that even less review time will be allocated to 4.0.0 work.

- who would be willing to help maintain this cassandra-5.0 branch?


I do not have the time so I will not be able to help with 5.0 work.

 - should it be kept external in a GH fork? Or would you rather have the
> branch in our main git repository?


To me GH fork is the same as not committed and not reviewed.  If a fork
would help the community then I am ok with it, but I don't see it as ready
to commit.

On Thu, Sep 10, 2020 at 12:58 PM Mick Semb Wever  wrote:

> We know we are turning away more and more contributions and new potential
> dev community with our 4.0 feature freeze, and it has been going on for a
> while now.
>
> I would like to suggest we create a cassandra-5.0 branch where we can start
> to queue up all reviewed and ready-to-go post-4.0 commits.
>
> This is not to distract from getting 4.0 out, where our primary focus is,
> but as a stop-gap in losing those contributions. The effort of the
> cassandra-5.0 branch maintenance: rebasing (git rerere); is just upon those
> that wish to take it on, and the branch can be located in whatever GH
> fork those
> individuals wish to keep it in. Tickets that have been reviewed and are
> (aside from the feature-freeze) ready to be committed, can be committed to
> the `cassandra-5.0` branch while their tickets remain in "Ready to Commit"
> status. The goal of this effort would be, a) we are giving the signal to
> contributors to get involved again (even while our primary focus in on
> stabilisation and testing efforts), and b) maintaining CI status on the
> sequence of commits that are ready to go into trunk post 4.0-rc.
>
> My questions are…
>  - who would be willing to help maintain this cassandra-5.0 branch?
>  - should it be kept external in a GH fork? Or would you rather have the
> branch in our main git repository?
>
> regards,
> Mick
>