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

Knoll Lars Lars.Knoll at theqtcompany.com
Mon Nov 30 13:21:04 CET 2015

On 30/11/15 13:13, "Development on behalf of Eskil A. Blomfeldt" <development-bounces at qt-project.org on behalf of eskil.abrahamsen-blomfeldt at theqtcompany.com> wrote:

>On 27. nov. 2015 14:53, Paul Olav Tvete wrote:
>> On Friday, November 27, 2015 02:23:01 PM Eskil A. Blomfeldt wrote:
>>> I think a batched change for all open reports with a "Fix version" !=
>>> "Some future release" would have to be part of this. A quick check
>>> reveals that we (for instance) currently have 27 unresolved bugs with
>>> fix version set to "5.3.0", so this might be a good clean-up to have in
>>> any case.
>> I thought we discussed that this should only apply to P1 (and af course P0)
>> bugs? If a bug is a blocker, it is by definition a P1. There is some sense in
>> allowing non-blocking bugs to have a Fix Version, to aid in planning.
>> As far as I can see, we have 157 bugs that have a Fix Version of 5.3.0 or
>> later. Of those,   one is P0, and 25 are P1. About half of those are for
>> 5.3/5.4.
>Personally, I don't see the need for that. The way it's used now, it's 
>not maintained, so you end up with open bug reports that claim they have 
>been fixed in a released Qt, which is just confusing. It would make the 
>system easier if that field refers to the version where we know the bug 
>has been / will be fixed, and not arbitrarily based on some plans or 
>user requests.
>In principle, that means there will be no unresolved bugs with P >= 2 
>that has a fix version set, which makes more sense since we are not 
>promising fix versions for non-blockers.

I think this makes most sense. The old way where we had a Fix Version set for open bugs is at the minimum confusing to users. Usually it’s worse, because it creates false expectations. Setting a Fix Version on an open bug is somewhat of a commitment by us that we will do what we can to get that bug fixed for this version. And that’s more the exception than the rule, ie. It makes the bug a showstopper for that release.


More information about the Development mailing list