>
> Should we clarify that part first by getting an idea of the status of the
> different CEPs and other big pieces of work?


CEP-20 (dynamic data masking) should hopefully be ready by the end of this
month.

It's composed by seven small tickets. Five of those tickets are ready, and
two are under review. All together it will be ~6K LOC, involving around 100
files.

On Thu, 9 Mar 2023 at 21:17, Mick Semb Wever <m...@apache.org> 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…
> >
> > 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?
>
>
> Ooops, actually we were using the -beta, and -rc fixVersion
> placeholders to denote the blockers once "the bridge was crossed"
> (while Urgent and Critical is used more broadly, e.g. patch releases).
> If we use this approach, then we could add a 5.0-alpha placeholder
> that indicates a consensus on tickets blocking the branching (if we
> agree alpha1 should be cut at the same time we branch…). IMHO such
> tickets should also still be marked as Urgent, but I suggest we use
> Urgent/Critical as an initial state, and the fixVersion placeholders
> where we have consensus or it is according to our release criteria
> :shrug:
>

Reply via email to