[Development] Suggestion for change on how blockers are marked in Jira
Eskil A. Blomfeldt
eskil.abrahamsen-blomfeldt at theqtcompany.com
Mon Nov 30 13:24:38 CET 2015
On 27. nov. 2015 14:42, Blasche Alexander wrote:
>> -----Original Message-----
>> From: Development [mailto:development-bounces at qt-project.org] On Behalf
>> Of Christian Kandeler
>> Sounds sensible, but what about all the existing bugs that have a "Fix
>> version" assigned? Won't they all become blockers now? Or can a script
>> wipe this field before the new semantics are announced?
> I would suggest that when release management sets Qt 5.x.y to released in Jira, every unresolved bug with a fix for tag of 5.x.y is shifted out. After all, after a release there should be no further unresolved issues for that particular release.
My take is that Qt 5.x.y cannot be released as long as there are
unresolved bugs with "fix for" set to 5.x.y.
>> So we could define it like this: If a bug report is open and has "Fix
>> version: Qt X.Y", then it will be considered a blocker for Qt X.Y.
> There is a small point missing here. Priorities still play a role here. P1 is blocker, every other priority is not a blocker but still targets 5.x.y. Of course depending on how close the release is the P4 fix may ot get accepted anymore and its fix for tag may have to be shifted eventually.
As mentioned in the answer to Paul, is someone sets "fix for" on a
non-blocker bug, I think it should either be cleared by the release team
or changed to P1. If you look at the current meta-task, there are
several P2s there, so it's not a given that the priority is set
correctly. Asking people to set two fields instead of one to get on the
blocker-list might just be adding more complexity without adding any
real value. My opinion is that having yet another meaning for the "fix
for" field when it's set on unresolved, lower-priority bugs (which is "I
think I might want to at some point fix this, maybe 5.x.y or something,
I dunno") doesn't have any actual value and makes the system more
confusing, so my suggestion is that we stop doing that (which I also
though was the consensus when we discussed moving to time-based
releases, but I don't remember how formalized the discussion was).
More information about the Development