On 27. nov. 2015 14:42, Blasche Alexander wrote:
-----Original Message-----
From: Development [mailto:[email protected]] 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
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
