An initial rough attempt to get together a queried view of outstanding scope for "4.0 GA blockers" is here on this quick filter: https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&projectKey=CASSANDRA&quickFilter=1719
JQL for a very similar query (pulls in about 10 more: catches sub-tasks for things that are improvements I think?): https://issues.apache.org/jira/issues/?filter=12348578 So that should at least help unblock anybody that's looking for "what's a more refined subset of things that are GA blockers for 4.0". Hopefully that's helpful. Be aware - that query does a dumb pull in of things that haven't updated in two weeks. That might be too aggressive, might be just fine, but be aware that there's tickets people are probably deeply into that don't need external prodding captured in that list along with just trivially stuck things that fell off radars. ~Josh On Tue, Mar 31, 2020 at 4:27 PM Jake Luciani <jak...@gmail.com> wrote: > I've been starting to look at the work left for 4.0 and was surprised to > see almost 1/2 the open tickets are Improvements. > Shouldn't the only criteria for 4.0 at this point should be bugs. > > Can we agree to move the improvements out to 4.0.x? > > -Jake > > On Tue, Mar 31, 2020 at 4:02 PM Ekaterina Dimitrova < > ekaterina.dimitr...@datastax.com> wrote: > > > Hello everyone, > > I think the project might benefit of one "filter applied" now on the > > current scope of JIRA tickets. > > And then, regular triage so focus is not lost. > > > > Up to now, I always try to look at the Release Lifecycle [1] criteria > when > > I open a new ticket in order to mark what is the target version of the > > patch. Also, I look from the perspective of the general code freeze. > > Hope I am doing it right. If those are strictly marked, do we need > > additional label for blocking tickets? Or we want to differentiate > between > > strong blockers and such patches which would be good if they land at a > > specific release but not mandatory? > > > > Why I am in for initial filter now? As I found many tickets opened in > > 2016...17...etc Things have changed a lot since then and there can be > > easily different PoV nowadays. > > > > I would be more than happy to help in any of these activities, too. > > > > Ekaterina > > > > [1] > > https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle > > > > > > > Begin forwarded message: > > > > > > *From:* David Capwell <dcapw...@gmail.com> > > > *Date:* 31 March 2020, 15:15:11 GMT-4 > > > *To:* dev@cassandra.apache.org > > > *Subject:* *Re: Idea: Marking required scope for 4.0 GA vs. optional* > > > *Reply-To:* dev@cassandra.apache.org > > > > > > What I'm used to is having two buckets for a release: tickets in the > > > release (if not complete they are blockers), and triage. How this is > done > > > isn't important but I do feel it's important to have both. > > > > > > Right now I don't see a active triage, but to Josh's point we would > need > > to > > > know who should first. Without answering, let me ask a question; > should I > > > (non committer) be adding blockers? If I add a blocker who should > verify > > it > > > should block? What if project members elect non-commiters to do this? > > > > > > > > > > > > On Mon, Mar 30, 2020, 8:45 AM Joshua McKenzie <jmcken...@apache.org> > > > wrote: > > > > > > Regardless of how we indicate optional vs. required for rel, are there > > > > > > strong opinions on who should set that metadata on tickets? Reporter? > > > > > > Assignee? One person? A group of people? > > > > > > > > > > > > On Sun, Mar 29, 2020 at 10:04 AM Joshua McKenzie <jmcken...@apache.org > > > > > > > > wrote: > > > > > > > > > FWIW, I don't care what we go with as long as we can differentiate > > > > > > tickets > > > > > > that are optional for the rel vs. tickets that are blockers and filter > > > > > > the > > > > > > JIRA board on them so people know where they should focus their effort. > > > > > > > > > The rest of it's just paint colors to me. > > > > > > > > > On Sun, Mar 29, 2020 at 9:24 AM Mick Semb Wever <m...@apache.org> > wrote: > > > > > > > > > > > > Alternatively, we could revert to using 4.0.X or 4.X as we once did to > > > > > > indicate something is targeting a release vs. blocking on inclusion > > > > > > for > > > > > > it. > > > > > > That seems to be a more "project JIRA hackish idiom", and one that's > > > > > > historically been confusing for people. At least with a label it would > > > > > > be > > > > > > clear with a name like "4.0-blocker", and we could then easily filter > > > > > > the > > > > > > JIRA board on it. > > > > > > > > > > > > > > > Now that I better understand Benedict's previous response (see the > > > > > > 'Dev Cassandra 4.0 Dev Work Status' thread¹), I'm leaning with his view > > > > > > for > > > > > > now. > > > > > > > > > I certainly missed the difference on how tickets ended up resolved as > > > > > > `4.0-alpha`. That unresolved `4.x` tickets were non-blockers that could > > > > > > still go into `4.0-alpha` if they satisfied the feature freeze and met > > > > > > someone's itch, while the unresolved `4.0-alpha` tickets were those the > > > > > > community declared as blockers. > > > > > > > > > Putting aside the discussion on what is a blocker, when it is > discovered > > > > > > to > > > > > > be a blocker (and vice versa). My confusion stemmed from the fact there > > > > > > was > > > > > > no specific alpha|beta versions for tickets to get resolved into, eg > > > > > > 4.0-alpha1, 4.0-alpha2, etc. So it wasn't just that the normal `.x` > > > > > > nomenclature got changed, but having accurate fix versions was also > > > > > > removed. If we added the specific alpha|beta versions then I wouldn't > > > > > > consider the approach to be a "hackish idiom" anymore. The 4.0-alpha, > > > > > > 4.0-beta and 4.0, versions become purely target versions like the `.x`, > > > > > > and > > > > > > no resolved ticket is ever assigned them. > > > > > > > > > The simpler we can make and document this the better. please. > > > > > > > > > regards, > > > > > > Mick > > > > > > > > > ¹) > > > > > > > > > > > > > > > > > > https://lists.apache.org/thread.html/rd06dabeaa10849795d15ee77c1a8c400b034dce005ac2d0b9366567a%40%3Cdev.cassandra.apache.org%3E > > > > > > > > > > > > > > > > > > > > -- > http://twitter.com/tjake >
