[Development] Bug management and jira workflow

[Blasche Alexander]

> -----Original Message-----
> From: development-bounces+alexander.blasche=digia.com at qt-project.org
> > >  - Who can prioritize bugs?
> > >
> > >     - whoever ask
> > >     - we will create a special group in jira
> >
> > we already have it (Triagers) ... it's just not "wired" yet.
> Good, who can "wire" the group?

Why do we need yet another group? Any approver can do that already. Or what am I missing?


> > we have some more groups which are kinda redundant or plain weird:
> > Developers vs. OGApprovers (the latter seems pointless; the former is a
> > default group, if i got it right).
> > Qt - ?!?
> > then there is a whole bunch of company-related groups. i don't think
> > they have much value at this point. just clear them out?
> > lastly, there is a lot of component-related groups. do we consider
> > these having any value?

They don't have much value. Unfortunately cleaning them out is a major pain as they have references to Permission, Notification and security schemes and here we are not even talking about all the custom filters.



 
> > >  - What does it mean “fixed version” in bug report
> > >
> > >     - we do not fill it until an issue is really fixed, which means
> > >     merged - we do not want to use the field for estimation
> >
> > i'm not sure i like that. i thoroughly dislike the idea of the "release
> > blocker meta-tasks". this is exactly what a prospective fix version plus
> > the right filter would do. that of course implies that the field must be
> > used exclusively as a deadline designation, not an expession of wishful
> > thinking.
> Yes, we were discussing which definition we should pick. We decided that
> not
> using the field for estimation is better from a random user point of view, that
> could check which Qt version is actually fixed, without cloning the repository.
> It doesn't create a wish list either. It seems to be also aligned with idea of
> time based releases, that changes are released, only if they were merged
> before a certain date.

I can see where there might be a confusion. However if I have a choice between the double loading of the Fix for Version and a release blocker task then I vote for the FixFor version field. The release blocker task doesn't even come close to a replacement. One of the most common filters is "What's unresolved and assigned to me for the next release?". Fix for is exactly what you need in this case. Also, as long as the task is not closed it can never be mistaken for a "really fixed" case anyway.

A somewhat better method would be to Split the FixFor field into two fields (e.g. PlannedFor vs FixedIn).

But even if we assume that FixFor really means released in version x.y.z, who is going to set it? You cannot set the field until very late in the process. That's exactly what you would do during the Verified->Closed transition (BTW the transition is called "Release") and the most likely candidate would be the release team. However this collides with the desire to merge the Resolved/Verified/Closed states because nobody transitions the verified tasks to closed. To me this sounds like the same problem. Nobody wants to clean the tasks right before the release.

On the other hand you can actually use the Verified to Closed transition to disambiguate the meaning of FixFor. If it is not closed then it always means that the field is an estimation. If it is closed then it's either part of a release line or it was rejected/invalid/ignored (which means FixFor is invalid anyway). It does imply some issue massaging shortly before the release though.

--
Alex