[Development] Bug management and jira workflow
jedrzej.nowacki at digia.com
Tue Jul 23 14:35:49 CEST 2013
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
> > - 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
> > - 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
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
More information about the Development