So, I'll say few things in bullet point form just for my general sentiment
1) I recognise the value of these efforts, and do not want to undermine them
2) I'm anyway very disappointed when individuals act on behalf of the project
without involving it in the decision-making or coordination
3) We're trying to strengthen project governance, and I find it worrisome to
even countenance a disregard for the frameworks that have been agreed
I'm not sure what the right approach is. I do not condone this situation, but
also do not want the project to suffer for it. I'll mull it over.
On 17/07/2020, 17:27, "Joshua McKenzie" <jmcken...@apache.org> wrote:
>
> I'm not aware of any of this, except the blog post proposal? What
> channels is this being coordinated on, and with whom?
Melissa Logan and Constantia are on this (she hit up the list a bit ago);
I'm not deep in the weeds - more of a contributor on the list that's agreed
to help out and collaborate as needed. There's tweets, the asf blog post
(these two are easy to shift around), some q&a's, some interviews lined up
I believe (these are far less easy to move around). I don't know if
coordination on this is happening actively on dev ML or directly w/the
people that volunteered to help out; I assume the latter.
I'm working on how I frame things and I think I failed earlier ( oops :) )
- a more helpful set of questions from me would have been "Who is going to
be negatively impacted if we let this ticket go into beta-2 instead of
beta-1, and how badly? Is there a way for us to communicate this delta to
them in favor of getting the beta out and, if so, is the value of getting
it out worth that risk?" Or something along those lines. Seems like you
managed to navigate my sleep deprived Friday morning "my personal UI is
incompletely booted" scatter - sorry about that.
we'll need a separate super-majority vote on ignoring the agreed beta
> rules
Hm. What happens if we all vote +1 on a release that doesn't 100% match the
agreed upon release rules? I'd initially advocate for us taking the stance
that each vote is what binds, giving us flexibility to navigate this nuance
on a case by case basis in the future. I haven't spent a lot of time
chewing on the implications of that statement though.
The devil of codification of rules like this is that there's always cases
that come up where the constraint of the rules inhibit progress without
commensurate value. In a community with all good faith actors assuming
positive intent, I think it's safe for us (and arguably more optimal) to
use those rules as the default minimal alignment that guides behavior but
we consider tickets and work on a case-by-case basis (much like with flaky
tests from alpha to beta, for instance).
For instance - if we approach this from a binary perspective, we have to go
down the rat-hole of defining what qualifies as an API formally, voting on
that, and codifying that to know what things the rules do and don't apply
to. My intuition is that's past the point of diminishing returns and we're
fine just being a bit more laissez-faire about things and applying our
collective judgement through our votes on each instance. My own bias
though, definitely receptive to other points of view on that.
On Fri, Jul 17, 2020 at 11:21 AM Benedict Elliott Smith
<bened...@apache.org>
wrote:
> > The cost to us delaying the beta over this ticket is risking our
> currently lined up coordination with journalists and other channels
>
> I'm not aware of any of this, except the blog post proposal? What
> channels is this being coordinated on, and with whom?
>
> If we agree to include this in beta-2, I'm OK with proceeding, but I think
> we'll need a separate super-majority vote on ignoring the agreed beta
> rules, which might be harder than just re-rolling the release?
>
>
> On 17/07/2020, 14:42, "Joshua McKenzie" <jmcken...@apache.org> wrote:
>
> This -1 is due to removal of an unused, unadvertised, and likely never
> working feature being removed in the config and raising an exception
> upon
> use. Is that accurate?
> >
> >
> I bid that we allow this into the beta and you agree to rescind your
> -1 as
> we can reasonably conclude the likelihood of any users running into
> this is
> basically zero. We can document it in the release notes as a known
> issue to
> be addressed in a subsequent beta release.
>
> The cost to us delaying the beta over this ticket is risking our
> currently
> lined up coordination with journalists and other channels (social
> media,
> etc) with marketing material and the ASF blog post that's lined up for
> the
> project.
>
> On Fri, Jul 17, 2020 at 5:14 AM Benedict Elliott Smith <
> bened...@apache.org>
> wrote:
>
> > -1
> >
> > Sorry, I dropped the ball on
> > https://issues.apache.org/jira/browse/CASSANDRA-15375
> >
> > It's ready to commit, if somebody can give it a quick +1, and would
> be
> > prohibited after first beta.
> >
> >
> > On 16/07/2020, 21:16, "Sumanth Pasupuleti" <
> > sumanth.pasupuleti...@gmail.com> wrote:
> >
> > +1 nb
> > Ran following CircleCI tests
> > j8_unit_tests (PASS)
> > j8_jvm_dtests (PASS)
> > j8_dtests (PASS)
> >
> > On Thu, Jul 16, 2020 at 10:18 AM Jordan West <jorda...@gmail.com
> >
> > wrote:
> >
> > > +1 nb
> > >
> > > On Thu, Jul 16, 2020 at 9:38 AM Yifan Cai <yc25c...@gmail.com>
> > wrote:
> > >
> > > > +1 nb
> > > >
> > > > ________________________________
> > > > From: Robert Stupp <sn...@snazy.de>
> > > > Sent: Thursday, July 16, 2020 2:59:34 AM
> > > > To: dev@cassandra.apache.org <dev@cassandra.apache.org>
> > > > Subject: Re: [VOTE] Release Apache Cassandra 4.0-beta1
> > > >
> > > > +1 (nb)
> > > >
> > > > —
> > > > Robert Stupp
> > > > @snazy
> > > >
> > > > > On 15. Jul 2020, at 20:07, Jasonstack Zhao Yang <
> > > > zhaoyangsingap...@gmail.com> wrote:
> > > > >
> > > > > +1 (nb)
> > > > >
> > > > > On Thu, 16 Jul 2020 at 01:28, Brandon Williams <
> dri...@gmail.com
> > >
> > > wrote:
> > > > >
> > > > >> +1 (binding)
> > > > >>
> > > > >> On Tue, Jul 14, 2020, 6:06 PM Mick Semb Wever <
> m...@apache.org>
> > wrote:
> > > > >>
> > > > >>> Proposing the test build of Cassandra 4.0-beta1 for
> release.
> > > > >>>
> > > > >>> sha1: 5e767711360ecc4bc05a7cd219f0e680bfada004
> > > > >>> Git:
> > > > >>>
> > > > >>>
> > > > >>
> > > >
> > >
> >
>
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta1-tentative
> > > > >>> Maven Artifacts:
> > > > >>>
> > > > >>>
> > > > >>
> > > >
> > >
> >
>
https://repository.apache.org/content/repositories/orgapachecassandra-1210/org/apache/cassandra/cassandra-all/4.0-beta1/
> > > > >>>
> > > > >>> The Source and Build Artifacts, and the Debian and RPM
> > packages and
> > > > >>> repositories, are available here:
> > > > >>>
> https://dist.apache.org/repos/dist/dev/cassandra/4.0-beta1/
> > > > >>>
> > > > >>> The vote will be open for 72 hours (longer if needed).
> > Everyone who
> > > has
> > > > >>> tested the build is invited to vote. Votes by PMC
> members are
> > > > considered
> > > > >>> binding. A vote passes if there are at least three
> binding +1s
> > and no
> > > > >> -1s.
> > > > >>>
> > > > >>> Eventual publishing and announcement of the 4.0-beta1
> release
> > will be
> > > > >>> coordinated, as described in
> > > > >>>
> > > > >>>
> > > > >>
> > > >
> > >
> >
>
https://lists.apache.org/thread.html/r537fe799e7d5e6d72ac791fdbe9098ef0344c55400c7f68ff65abe51%40%3Cdev.cassandra.apache.org%3E
> > > > >>>
> > > > >>> [1]: CHANGES.txt:
> > > > >>>
> > > > >>>
> > > > >>
> > > >
> > >
> >
>
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-beta1-tentative
> > > > >>> [2]: NEWS.txt:
> > > > >>>
> > > > >>>
> > > > >>
> > > >
> > >
> >
>
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-beta1-tentative
> > > > >>>
> > > > >>
> > > >
> > > >
> > >
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
