I thought about this a bit more overnight - if I'm arguing that most work would be fast forward merges to trunk if we branched beta due to the type of work going into beta, the inverse argument should hold that most merges into a feature branch would be fast forward or minimal. So I think the basic motivation to push for branching that I opened this thread with is actually largely moot.
It did surface something else for me concerning our posture as a project and long term health from how we're signaling inclusivity to new contributors and how we can encourage diversity in contributions on the project. No need to conflate that with this thread however. Thanks for the input, and definitely would love more visibility into some of the things people have been working on that aren't yet captured in JIRA. On Sat, Jun 27, 2020 at 12:57 AM Scott Andreas <sc...@paradoxica.net> wrote: > Great point re: increasing the public visibility of testing and validation > activity. > > I’ll partner with a few contributors I work with to prep a summary of our > findings that aren’t already captured in JIRA tickets we’ve filed against > 3.x and 4.0 so far (as David mentioned, many issues we’re identifying are > 3.0 regressions). > > Some of these findings are notable, and many are quite standard — the type > of experience that’s built from prep to deploy a major piece of software at > large scale with a high degree of automation and confidence. But the pieces > that are “standard” are the category of work that anyone automating large > Cassandra 4.0 deployments must undertake and are things Cassandra’s users > will need to be aware of. I’m sure those findings will be valuable to all > on this list. > > Not all blocking issues involve a combination of range tombstones, > legacylayout, complex types, paging state, mixed-version clusters, and > reverse iteration. :) > > — Scott > > > On Jun 26, 2020, at 7:10 PM, Joshua McKenzie <jmcken...@apache.org> > wrote: > > > > > >> > >> > >> I've seen a lot of talk from some quarters of a new approach to quality, > >> but so far there have been few contributions from the same quarters > >> > > Just a heads up - this comes across as passive aggressive sniping. I'm > sure > > you didn't mean it as such but it does read that way (at least to me). > > > > When it comes to quality, much like you said in another thread Benedict I > > think we all need to be honest with ourselves. There's been a lot of talk > > from *all* quarters but outside a lot of expression of intent across many > > fronts (verbal, ML, JIRA, slack), very little has publically materialized > > on the project to this point that I know of. > > > > I cleared out assignees on 40_quality_testing tickets earlier this week > > (overloading shepherds in this field was a mistake IMO - that's on me) > > which has clarified for some contributors that they can take that work > on. > > There's still considerable uncertainty as to what the scope is for those > > tickets and nobody really replied to Jordan pinging shepherds for > > clarification a long while ago. > > > > > > > > On Fri, Jun 26, 2020 at 8:44 PM Dinesh Joshi <djo...@apache.org> wrote: > > > >>>> On Jun 26, 2020, at 3:45 PM, David Capwell <dcapw...@gmail.com> > wrote: > >>> > >>> the ability to test their impact. Even simple things become hard given > >> the > >>> fact only committers can run Jenkins tests, or you pay money to be able > >> to > >>> run the tests... If the intent is to make it easier for new people to > >>> contribute to the project, shouldn't the focus be on fixing their pain > >>> points such as testing? > >> > >> +1 on not branching and keeping focus on testing and fixing 4.0. > >> > >> I am sorry about the situation for non-committers. I tried reaching out > to > >> legal and infra in the past without a great response. If someone in the > >> community has a way to reach out and get clarity on problems affecting > our > >> contributors, it would be great. Otherwise, I will try to bug them > again. > >> > >> 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 > >
