[Development] Suggestion for change on how blockers are marked in Jira

[Eskil A. Blomfeldt]

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).

-- Eskil