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 > > > > >
