> We do have the metadata, but yes it requires some work… My wording was poor; we have the *potential* to have this metadata, but to my knowledge we don't have a muscle of consistently setting this, or any kind of heuristic to determine when something should block a release or not. At least on 4.0 and 4.1, it seemed this was a bridge we crossed informally in the run up to a date trying to figure out what to include or discard.
> The project previously made an agreement to one release a year, I don't recall the details (and searching our... rather active threads is an undertaking) - our site has a blog post here: https://cassandra.apache.org/_/blog/Apache-Cassandra-Changelog-7-May-2021.html, that states: "The community has agreed to one release every year, plus periodic trunk snapshots". While it reads like "one a calendar year" to me, at the end of the day what's important to me is we do right by our users. So whether we interpret that as every 12 months, once per calendar year, once every July with a freeze in May train style, all fine by me actually. I more or less stand by "just not 'release monthly' and not 'release once every three years'. :) Got any clarity there? > I (and others) wish to do the exercise of running through our 5.x list and > pushing out everything we can see with no commitment or activity (and also > closing out old and now irrelevant/inapplicable tickets) (and this will be > done via a proposed filter). But a question here is the fixVersion can infer > where a ticket can be applied (appropriateness) or where we foresee it > landing (roadmap). I'm +1 to this. If people want something to be different they can just toggle it back and bring it to the ML or slack. For everything not urgent or a blocker, does it matter whether something has a fixver of where we think it's going to land or where we'd like to see it land? At the end of the day, neither of those scenarios will actually shift a release date if we're proactively putting "blocker / urgent" status on new features, improvements, and bugs we think are significant enough to delay a release right? On Thu, Mar 9, 2023, at 3:17 PM, Mick Semb Wever wrote: >> One place we've been weak historically is in distinguishing between tickets >> we consider "nice to have" and things that are "blockers". We don't have any >> metadata that currently distinguishes those two, so determining what our >> burndown leading up to 5.0 looks like is a lot more data massaging and >> hand-waving than I'd prefer right now. > > > We distinguish "blockers" with `Priority=Urgent` or `Severity=Critical`, or > by linking the ticket as blocking to a specific ticket that spells it out. We > do have the metadata, but yes it requires some work… > > The project previously made an agreement to one release a year, akin to a > release train model, which helps justify why fixVersion 5.x has just fallen > to be "next". (And then there is no "burn-down" in such a model.) > > Our release criteria, especially post-branch, demonstrates that we do > introduce and rely on "blockers". If we agree that certain exceptional CEPs > are "blockers", a la warrant delaying the release date, using this approach > seems to fit in appropriately. > > When I (just) folded fixVersion 4.2 into 5.0 (and 4.x into 5.x), I also > created 5.1.x and 6.x. I (and others) wish to do the exercise of running > through our 5.x list and pushing out everything we can see with no commitment > or activity (and also closing out old and now irrelevant/inapplicable > tickets) (and this will be done via a proposed filter). But a question here > is the fixVersion can infer where a ticket can be applied (appropriateness) > or where we foresee it landing (roadmap). For example we mark bugs with the > fixVersions ideally they should be applied to, regardless of whether anyone > comes to address them or not. > > >
