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" <jak...@gmail.com> 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
<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" <jak...@gmail.com> 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" <jak...@gmail.com> 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" <dri...@gmail.com>
> wrote:
> > >
> > > On Thu, Sep 24, 2020 at 9:55 AM Benedict Elliott Smith
> > > <bened...@apache.org> 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
>
>
--
http://twitter.com/tjake
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
