headers
matanya | 16 Aug 2012 15:17
Picon

organize a bug triage

Hello,

We didn't have a bug triage since May. I suggest organizing one in a few
weeks (say 2?)

I agree to take care of this if it is widely supported.
How about focusing on patch triage?

I mean reviewing bugs with patches attached but not in gerrit.

Any other subject would be good as well.

opinions?

Matanya


_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Permalink | Reply |
headers
Al Snow | 16 Aug 2012 17:02
Picon
Favicon
Gravatar

Re: organize a bug triage


I see 3 types of bug triages:

 a. Up-front
  * Confirming bugs and assigning them to developers.
  * STATUS is "UNCONFIRMED", "NEW", "REOPENED"; RESOLUTION is N/A

 b. Verify fix
    * Verifying fixes (STATUS is "RESOLVED"; RESOLUTION is "FIXED")

 c. Accept non-fix resolution
  * Accepting all non-fixed resolution.
  * STATUS is RESOLVED; RESOLUTION is not "FIXED" (I count at least 5 non-"FIXED" RESOLUTION values)

Here is a Wikimedia bug table report:
https://bugzilla.wikimedia.org/report.cgi?y_axis_field=product&x_axis_field=bug_status&z_axis_field=&query_format=report-table&format=table&action=wrapNote
the different format at the bottom of the web page.
Hope this helps,Al Snow
###########################################################################

Date: Thu, 16 Aug 2012 16:17:15 +0300
From: matanya <at> moses.co.il
To: wikitech-l <at> lists.wikimedia.org
Subject: [Wikitech-l] organize a bug triage

Hello,

We didn't have a bug triage since May. I suggest organizing one in a few
weeks (say 2?)
(Continue reading)

Permalink | Reply |
headers
Andre Klapper | 16 Aug 2012 19:21
Picon

Re: organize a bug triage

Hi Al,

On Thu, 2012-08-16 at 11:02 -0400, Al Snow wrote:
> I see 3 types of bug triages:

Thanks. These could be added to
https://www.mediawiki.org/wiki/Project:WikiProject_Bug_Squad/Activities

Some more ideas could be to concentrate on a single module (e.g.
extensions) or to update/try to reproduce issues that were reported for
old versions and have not seen changes for a while (in Bugzilla's
query.cgi under "Search By Change History" you can replace "Now" by e.g.
"-731d" to get all tickets without any changes for the last two years).
Or to update/retest the reports that you filed yourself, or.....

>  a. Up-front
>   * Confirming bugs and assigning them to developers.
>   * STATUS is "UNCONFIRMED", "NEW", "REOPENED"; RESOLUTION is N/A

I'd say that this normally requires knowledge which developers work on
what. To me that makes it a harder task for "newbies" and might require
people that have been in the community for quite a while.
Just trying to clarify potential prerequisites.

>  b. Verify fix
>     * Verifying fixes (STATUS is "RESOLVED"; RESOLUTION is "FIXED")

At least for more recent fixes this might require running (potentially
unstable) code from latest git master instead of a (stable) tarball?
Somebody please correct me if I'm wrong.
(Continue reading)

Permalink | Reply |
headers
Al Snow | 16 Aug 2012 19:31
Picon
Favicon
Gravatar

Re: organize a bug triage


Andre,
> > c. Accept non-fix resolution
> > * Accepting all non-fixed resolution.
> > * STATUS is RESOLVED; RESOLUTION is not "FIXED" (I count at least 5 non-"FIXED" RESOLUTION values)

> Sorry but I don't know what you mean by "accepting" here. :/
When I look at the non-"FIXED" RESOLUTIONs that I know about (INVALID, WONTFIX, LATER, DUPLICATE, and
WORKSFORME), the next step is to REOPEN it or accept the resolution and change status to VERIFIED.
Here is a chart with these RESOLUTIONS: https://bugzilla.wikimedia.org/reports.cgi?product=Wikimedia&banner=1&datasets=INVALID&datasets=WONTFIX&datasets=LATER&datasets=DUPLICATE&datasets=WORKSFORME

Thanks for the question,
Al Snow

> From: andre_klapper <at> gmx.net
> To: wikitech-l <at> lists.wikimedia.org
> Date: Thu, 16 Aug 2012 19:21:12 +0200
> Subject: Re: [Wikitech-l] organize a bug triage
> 
> Hi Al,
> 
> On Thu, 2012-08-16 at 11:02 -0400, Al Snow wrote:
> > I see 3 types of bug triages:
> 
> Thanks. These could be added to
> https://www.mediawiki.org/wiki/Project:WikiProject_Bug_Squad/Activities
> 
> Some more ideas could be to concentrate on a single module (e.g.
> extensions) or to update/try to reproduce issues that were reported for
> old versions and have not seen changes for a while (in Bugzilla's
(Continue reading)

Permalink | Reply |
headers
Andre Klapper | 16 Aug 2012 19:52
Picon

Re: organize a bug triage

Hi Al,

[Expectations, workflows and manpower among FOSS projects differ so
please take my comments with a grain of salt as I don't follow the
Wikimedia project that closely.]

On Thu, 2012-08-16 at 13:31 -0400, Al Snow wrote:
> > > c. Accept non-fix resolution
> > > * Accepting all non-fixed resolution.
> > > * STATUS is RESOLVED; RESOLUTION is not "FIXED" (I count at least 5 non-"FIXED" RESOLUTION values)
> 
> > Sorry but I don't know what you mean by "accepting" here. :/
> When I look at the non-"FIXED" RESOLUTIONs that I know about (INVALID,
> WONTFIX, LATER, DUPLICATE, and WORKSFORME), the next step is to REOPEN
> it or accept the resolution and change status to VERIFIED.

...or to just leave a report as it is? :)

REOPENing normally happens if the reporter, developer or another party
interested in fixing the issue realizes that a committed fix did not fix
the issue, or to signal disagreement. I'm not convinced if triagers can
help here to save any of those persons some time.

Also I don't really see who it helps to verify RESOLVED DUPLICATE.
Personally I rather consider it a waste of time (anybody is free to
disagree of course) as efforts are better spent on general triaging like
identifying duplicates etc. which seems to be a bigger help for users
and developers.

For the other four options I normally leave it to the reporter. For
(Continue reading)

Permalink | Reply |
headers
Chad | 16 Aug 2012 20:01
Picon

Re: organize a bug triage

Triaging already closed bugs seems like a huge waste of time when there's
so many open bugs that need love.

-Chad
On Aug 16, 2012 1:53 PM, "Andre Klapper" <andre_klapper <at> gmx.net> wrote:

> Hi Al,
>
> [Expectations, workflows and manpower among FOSS projects differ so
> please take my comments with a grain of salt as I don't follow the
> Wikimedia project that closely.]
>
> On Thu, 2012-08-16 at 13:31 -0400, Al Snow wrote:
> > > > c. Accept non-fix resolution
> > > > * Accepting all non-fixed resolution.
> > > > * STATUS is RESOLVED; RESOLUTION is not "FIXED" (I count at least 5
> non-"FIXED" RESOLUTION values)
> >
> > > Sorry but I don't know what you mean by "accepting" here. :/
> > When I look at the non-"FIXED" RESOLUTIONs that I know about (INVALID,
> > WONTFIX, LATER, DUPLICATE, and WORKSFORME), the next step is to REOPEN
> > it or accept the resolution and change status to VERIFIED.
>
> ...or to just leave a report as it is? :)
>
> REOPENing normally happens if the reporter, developer or another party
> interested in fixing the issue realizes that a committed fix did not fix
> the issue, or to signal disagreement. I'm not convinced if triagers can
> help here to save any of those persons some time.
>
(Continue reading)

Permalink | Reply |
headers
Al Snow | 16 Aug 2012 20:19
Picon
Favicon
Gravatar

Re: organize a bug triage


Thanks Chad and Andre for your responses.
I am new to the community and did not know that RESOLVED bugs were considered CLOSED. Thanks for the update.

Al Snow

> Date: Thu, 16 Aug 2012 14:01:33 -0400
> From: innocentkiller <at> gmail.com
> To: wikitech-l <at> lists.wikimedia.org
> Subject: Re: [Wikitech-l] organize a bug triage
> 
> Triaging already closed bugs seems like a huge waste of time when there's
> so many open bugs that need love.
> 
> -Chad
> On Aug 16, 2012 1:53 PM, "Andre Klapper" <andre_klapper <at> gmx.net> wrote:
> 
> > Hi Al,
> >
> > [Expectations, workflows and manpower among FOSS projects differ so
> > please take my comments with a grain of salt as I don't follow the
> > Wikimedia project that closely.]
> >
> > On Thu, 2012-08-16 at 13:31 -0400, Al Snow wrote:
> > > > > c. Accept non-fix resolution
> > > > > * Accepting all non-fixed resolution.
> > > > > * STATUS is RESOLVED; RESOLUTION is not "FIXED" (I count at least 5
> > non-"FIXED" RESOLUTION values)
> > >
> > > > Sorry but I don't know what you mean by "accepting" here. :/
(Continue reading)

Permalink | Reply |
headers
bawolff | 16 Aug 2012 20:27
Picon

organize a bug triage

> Hello,
>
> We didn't have a bug triage since May. I suggest organizing one in a few
> weeks (say 2?)
>
> I agree to take care of this if it is widely supported.
> How about focusing on patch triage?
>
> I mean reviewing bugs with patches attached but not in gerrit.
>
> Any other subject would be good as well.
>
> opinions?
>
> Matanya

I  think this is an excellent idea.

A patch triage sounds like a good idea, especially for a first such
triage after no one doing them in a while. After all even in magical
git land, its still important to respond to bugzilla patches. If this
triage session is successful, I think doing future sessions of
"prioritize and assign the incoming bugs" would also be good

/me just really misses all hexmode's bug spam :)

Re Al Snow
> b. Verify fix
>   * Verifying fixes (STATUS is "RESOLVED"; RESOLUTION is "FIXED")
>
(Continue reading)

Permalink | Reply |
headers
Mark A. Hershberger | 18 Aug 2012 17:31
Gravatar

Re: organize a bug triage


On 08/16/2012 09:17 AM, matanya wrote:
> We didn't have a bug triage since May. I suggest organizing one in
> a few weeks (say 2?)

Wow! Thanks for taking this on!  I'm busy with non-MW work, but I do
have some time to help out.

Please CC me personally on any triage announcements or ping me on IRC
(hexmode).  Thanks!

--

-- 
http://hexmode.com/

Human evil is not a problem.  It is a mystery.  It cannot be solved.
              -- When Atheism Becomes a Religion, Chris Hedges
Permalink | Reply |
headers
Tyler Romeo | 19 Aug 2012 07:42
Picon
Gravatar

Re: organize a bug triage

I think this is a great idea, but I also have a new idea for how we might
go about using the RESOLVED -> VERIFIED -> CLOSED workflow in BugZilla,
rather than just treating resolved as closed. One thing I noticed about MW
is that we're very much lacking in the test planning area. What if a bug is
marked as verified if either a) somebody makes and commits a test case for
it or b) it is determined that a test case is not applicable. That way
we'll have automated tests ensuring every bug we fix doesn't come back
again. Any thoughts?

*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerromeo <at> gmail.com

On Sat, Aug 18, 2012 at 11:31 AM, Mark A. Hershberger <mah <at> everybody.org>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 08/16/2012 09:17 AM, matanya wrote:
> > We didn't have a bug triage since May. I suggest organizing one in
> > a few weeks (say 2?)
>
> Wow! Thanks for taking this on!  I'm busy with non-MW work, but I do
> have some time to help out.
>
> Please CC me personally on any triage announcements or ping me on IRC
> (hexmode).  Thanks!
>
(Continue reading)

Permalink | Reply |
headers
Andre Klapper | 19 Aug 2012 13:23
Picon

Re: organize a bug triage

On Sun, 2012-08-19 at 01:42 -0400, Tyler Romeo wrote:
> I think this is a great idea, but I also have a new idea for how we might
> go about using the RESOLVED -> VERIFIED -> CLOSED workflow in BugZilla,
> rather than just treating resolved as closed. One thing I noticed about MW
> is that we're very much lacking in the test planning area. What if a bug is
> marked as verified if either a) somebody makes and commits a test case for
> it or b) it is determined that a test case is not applicable. That way
> we'll have automated tests ensuring every bug we fix doesn't come back
> again. Any thoughts?

I fail to see a strong relation with the VERIFIED status. One could also
argue in favor of writing a testcase together with writing the fix for a
specific bug report (so relating it to RESOLVED FIXED instead).

But this is getting off-topic for the "bug triage" subject anyway. :)

andre
--

-- 
Andre Klapper (maemo.org bugmaster & GNOME Bugsquad)
http://blogs.gnome.org/aklapper/
Permalink | Reply |

Gmane