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
ity, 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
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
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
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
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
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
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
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
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
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
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
> 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
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
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
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
>
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
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,
> 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:
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,
> 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
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
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
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
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
> 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
> 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
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,
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
>
> 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
> 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
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
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
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
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
> 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
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
>
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
>
> 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
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
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
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
> 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
> 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
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
> 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
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
> 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,
>
> 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
51 matches
Mail list logo
