> > some marketing blitz that wasn't even publicly discussed but I won't stand > in the way. > 2) I'm anyway very disappointed when individuals act on behalf of the > project without involving it in the decision-making or coordination
This topic was opened on the public ML and volunteers asked for and replied, and the pmc was engaged to review and revise the marketing blog. We currently don't do all dev on the public ML so it's pretty consistent with that precedent. If we want this behavior to be changed or revised (for instance, any and all discussion or coordination for any and all individual project contributors engaging with journalists or providing quotes about the release), that's something we should discuss separately on another thread. Let's not derail this discussion further and I'd ask we be mindful about how we characterize new contributor contributions as our community evolves. On Fri, Jul 17, 2020 at 2:24 PM Mick Semb Wever <m...@apache.org> wrote: > > 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? > > > This position, on a release vote, by precedence sounds more like a -0. A > valid concern has been raised, needs to be heard, but can and should be > resolved within this thread and vote. It has my vote to be added to 4.0- > beta2. > > > I think it's worth pointing out that this ticket was never marked with a > fix-version "4.0-alpha", so it was never visible as a blocker to the first > beta release. Being strict here IMHO would mean reverting the commit and > posting it to 4.1/5.0, rather blocking beta1. > > And… isn't the only thing that breaks API compatibility (and our beta > rules) > here is this one line: > > https://github.com/apache/cassandra/commit/d8993934e976d8edb94cbfe2974688dac63c5db5#diff-4805e34bd9553ede03778be66ddc06c7R268 > > > I can cut a new 4.0-beta1, no problems there. The bar to re-cutting a > proposed > release should be low enough that it's an easy enough call to request. I > will wait a few hours before doing so, to see what eventuates here… >
