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
