Bug 201944
| Summary: | Add flag to support 'errata notice' request tracking | ||
|---|---|---|---|
| Product: | Services | Reporter: | Glen Barber <gjb> |
| Component: | Bug Tracker | Assignee: | Bugmeister <bugmeister> |
| Status: | Closed Overcome By Events | ||
| Severity: | Affects Only Me | CC: | re, secteam |
| Priority: | --- | Keywords: | easy, feature, needs-qa |
| Version: | unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Glen Barber
2015-07-28 12:17:42 UTC
Would errata-notice suffice as the flag name, given the value of the field indicates the nature of the request? ie: - desired-as-candidate (?) - accepted|done (+) - rejected|not-needed (-) (In reply to Kubilay Kocak from comment #1) > Would errata-notice suffice as the flag name, given the value of the field > indicates the nature of the request? ie: > > - desired-as-candidate (?) > - accepted|done (+) > - rejected|not-needed (-) I think "en-candidate" as the flag name is more appropriate, because we do not always know how intrusive the fix is until the change is committed. That said, the fields would ideally be: - needs-review (?) - yes (+) - rejected|no (-) If for example an issue comes in, the bug is fixed (committed), and it's an Errata Notice candidate that the user (reporter, or assignee) sets, or asks for. * What would the flag value be set to when complete (accepted)? * How would the Errata Notice commit take place? * Separate blocking issue? * Same issue? It should be clear in the issues final (closed) state what has happened, in the case where an issue is fixed and had an EN produced for it. I'm not trying to make a mountain of a molehill (in naming things), but it would be nice if the flag name was easy to understand and obvious in terms of how to use it from a user perspective. If it was named en-candidate, set to ? when requested, then - if rejected (post-review), then the final issue state would translate to: 'This issue and its fix was not an errata notice candidate' versus If it was named errata-notice, set to ? when requested, then - if rejected (post review), would translate to: 'This issue and it's fix was rejected for creating an errata notice' The latter is much clearer. I suppose the shorter version of what I'm trying to say, another way is, all flags are 'candidates' already. Eg: exp-run ? = expr-run candidate -> reject|accept merge‑quarterly ? = quarterly branch merge candidate -> reject|accept (In reply to Kubilay Kocak from comment #3) > If for example an issue comes in, the bug is fixed (committed), and it's an > Errata Notice candidate that the user (reporter, or assignee) sets, or asks > for. > > * What would the flag value be set to when complete (accepted)? The flag would be irrelevant in this case. The PR should be closed when the fix is committed to the stable branches. The intent here is solely to track the candidates, not track the ENs themselves. > * How would the Errata Notice commit take place? > * Separate blocking issue? > * Same issue? > These also are not relevant here. The EN commit is handled by so@ when the EN is published. > It should be clear in the issues final (closed) state what has happened, in > the case where an issue is fixed and had an EN produced for it. > Again, this is only for re@/secteam@ to track candidates for ENs, not for issuing the EN. > I'm not trying to make a mountain of a molehill (in naming things), but it > would be nice if the flag name was easy to understand and obvious in terms > of how to use it from a user perspective. > > If it was named en-candidate, set to ? when requested, then - if rejected > (post-review), then the final issue state would translate to: > > 'This issue and its fix was not an errata notice candidate' > > versus > > If it was named errata-notice, set to ? when requested, then - if rejected > (post review), would translate to: > > 'This issue and it's fix was rejected for creating an errata notice' > > The latter is much clearer. > This is not what was intended when this flag was requested. (See above.) > I suppose the shorter version of what I'm trying to say, another way is, all > flags are 'candidates' already. Eg: > > exp-run ? = expr-run candidate -> reject|accept > merge‑quarterly ? = quarterly branch merge candidate -> reject|accept This is no longer requested. |