[Development] Bug management and jira workflow

[Jedrzej Nowacki]

On Tuesday 23. July 2013 13.57.26 Oswald Buddenhagen wrote:
> On Tue, Jul 23, 2013 at 01:25:44PM +0200, Jedrzej Nowacki wrote:
> >   At the Qt Contributor Summit, we had a really good discussion about
> >   bugs and
> > 
> > jira, here is the summary:
> >  - We agreed on “triaging” definition. Triaging consist of:
> >     - checking if a bug report is sensible. It means the reported issue
> >     is not
> > 
> > a result of a user mistake, use of undefined behavior etc.
> 
> for build-related problems that sounds a lot easier than it actually is.
> not saying that the process is not applicable, but i really could use
> some qualified help.
Sure, the idea was to make the process significantly lighter then fixing the 
bug.

> >  - 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?

> 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?
We haven't discussed that. From my point of view the old groups may be 
removed.

> >  - 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.
 
> >  - Jira workflow was designed for much bigger team, that includes QA
> > 
> > department, it should be simplify
> > 
> >     - Resolved, Verified and Closed should be merged to a single state.
> >     Nobody
> > 
> > is going through Resloved bugs to verify them.
> 
> i was considering slashing only Verified, but ran into awkwardness while
> pondering state transitions, so i guess i agree with this radical cure.
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development