Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Wikipedia: Wikitech

organize a bug triage

 

 

Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded


matanya at moses

Aug 16, 2012, 6:17 AM

Post #1 of 14 (2594 views)
Permalink
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
Attachments: signature.asc (0.88 KB)


jasnow at hotmail

Aug 16, 2012, 8:02 AM

Post #2 of 14 (2477 views)
Permalink
Re: organize a bug triage [In reply to]

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
To: wikitech-l [at] lists
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?)

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
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


andre_klapper at gmx

Aug 16, 2012, 10:21 AM

Post #3 of 14 (2474 views)
Permalink
Re: organize a bug triage [In reply to]

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.
Again, just potential prerequisites.

> 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. :/

@matanya et al:
I'd highly appreciate if you could try to document how to organize a
bugday for future organizers (e.g. announcement, potential problems),
and maybe alongside update (or identify gaps in) the Triage Guide at
https://www.mediawiki.org/wiki/Bug_management/How_to_triage whenever
needed. (But that guide is rather incomplete currently anyway.)

Thanks,
andre
--
Andre Klapper (maemo.org bugmaster & GNOME Bugsquad)
http://blogs.gnome.org/aklapper/


_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


jasnow at hotmail

Aug 16, 2012, 10:31 AM

Post #4 of 14 (2479 views)
Permalink
Re: organize a bug triage [In reply to]

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
> To: wikitech-l [at] lists
> 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
> 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.
> Again, just potential prerequisites.
>
> > 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. :/
>
> @matanya et al:
> I'd highly appreciate if you could try to document how to organize a
> bugday for future organizers (e.g. announcement, potential problems),
> and maybe alongside update (or identify gaps in) the Triage Guide at
> https://www.mediawiki.org/wiki/Bug_management/How_to_triage whenever
> needed. (But that guide is rather incomplete currently anyway.)
>
> Thanks,
> andre
> --
> Andre Klapper (maemo.org bugmaster & GNOME Bugsquad)
> http://blogs.gnome.org/aklapper/
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


andre_klapper at gmx

Aug 16, 2012, 10:52 AM

Post #5 of 14 (2473 views)
Permalink
Re: organize a bug triage [In reply to]

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
example verifying a WONTFIX (=stating for a second time that the request
will not receive a fix) might make a reporter feel less acknowledged for
spending time on reporting a bug or request.

andre

PS: For anybody _really_ interested in discussing the use of the
VERIFIED status in Bugzilla I recommend a recent thread on the Mozilla
dev-platform/dev-quality mailing lists at
https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.platform/gn9SC8wQ4sA[1-25]

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


_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


innocentkiller at gmail

Aug 16, 2012, 11:01 AM

Post #6 of 14 (2475 views)
Permalink
Re: organize a bug triage [In reply to]

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> 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.
>
> 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
> example verifying a WONTFIX (=stating for a second time that the request
> will not receive a fix) might make a reporter feel less acknowledged for
> spending time on reporting a bug or request.
>
> andre
>
> PS: For anybody _really_ interested in discussing the use of the
> VERIFIED status in Bugzilla I recommend a recent thread on the Mozilla
> dev-platform/dev-quality mailing lists at
>
> https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.platform/gn9SC8wQ4sA[1-25]
>
> --
> Andre Klapper (maemo.org bugmaster & GNOME Bugsquad)
> http://blogs.gnome.org/aklapper/
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


jasnow at hotmail

Aug 16, 2012, 11:19 AM

Post #7 of 14 (2475 views)
Permalink
Re: organize a bug triage [In reply to]

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
> To: wikitech-l [at] lists
> 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> 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.
> >
> > 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
> > example verifying a WONTFIX (=stating for a second time that the request
> > will not receive a fix) might make a reporter feel less acknowledged for
> > spending time on reporting a bug or request.
> >
> > andre
> >
> > PS: For anybody _really_ interested in discussing the use of the
> > VERIFIED status in Bugzilla I recommend a recent thread on the Mozilla
> > dev-platform/dev-quality mailing lists at
> >
> > https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.platform/gn9SC8wQ4sA[1-25]
> >
> > --
> > Andre Klapper (maemo.org bugmaster & GNOME Bugsquad)
> > http://blogs.gnome.org/aklapper/



_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


bawolff+wn at gmail

Aug 16, 2012, 11:27 AM

Post #8 of 14 (2494 views)
Permalink
organize a bug triage [In reply to]

> 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")
>
> 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)

I thought that's what Wikipedia was for (joke, but only sort of.
There's enough open bugs in need of love that verifying a RESOLVED
WORKSFORME bug really works for us doesn't seem that useful)

-bawolff

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


mah at everybody

Aug 18, 2012, 8:31 AM

Post #9 of 14 (2467 views)
Permalink
Re: organize a bug triage [In reply to]

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

- --
http://hexmode.com/

Human evil is not a problem. It is a mystery. It cannot be solved.
-- When Atheism Becomes a Religion, Chris Hedges
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFQL7VXc17xCi38v/URAsV7AKCiYFvnnIfSu8sU+/OvVxnboWQWWwCghdMy
JpR0it7vfHlOOfr8OX5VbF8=
=iBFq
-----END PGP SIGNATURE-----

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


tylerromeo at gmail

Aug 18, 2012, 10:42 PM

Post #10 of 14 (2476 views)
Permalink
Re: organize a bug triage [In reply to]

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



On Sat, Aug 18, 2012 at 11:31 AM, Mark A. Hershberger <mah [at] everybody>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!
>
> - --
> http://hexmode.com/
>
> Human evil is not a problem. It is a mystery. It cannot be solved.
> -- When Atheism Becomes a Religion, Chris Hedges
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iD8DBQFQL7VXc17xCi38v/URAsV7AKCiYFvnnIfSu8sU+/OvVxnboWQWWwCghdMy
> JpR0it7vfHlOOfr8OX5VbF8=
> =iBFq
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


andre_klapper at gmx

Aug 19, 2012, 4:23 AM

Post #11 of 14 (2486 views)
Permalink
Re: organize a bug triage [In reply to]

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/


_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


matanya at moses

Aug 22, 2012, 12:42 AM

Post #12 of 14 (2439 views)
Permalink
organize a bug triage [In reply to]

Hi again,

I have started an etherpad here:

http://etherpad.wikimedia.org/BugTriage-2012-09

Please help improve and comment on date/time/bugs choosen

matanya
Attachments: signature.asc (0.88 KB)


sumanah at wikimedia

Aug 22, 2012, 1:26 PM

Post #13 of 14 (2436 views)
Permalink
Re: organize a bug triage [In reply to]

On 08/22/2012 03:42 AM, matanya wrote:
> Hi again,
>
> I have started an etherpad here:
>
> http://etherpad.wikimedia.org/BugTriage-2012-09
>
> Please help improve and comment on date/time/bugs choosen
>
> matanya

Thanks for setting this up, Matanya! I've publicized this 5 September
patch triage to follow a bit more of
https://www.mediawiki.org/wiki/Bug_Management/Meeting_prep .

Since this is a patch review triage, you might be interested in using
Rusty Burchfield's (gicode) automated testing of patches for a little
more information (code at https://github.com/GICodeWarrior/patch-tester
, 16 August run at
https://docs.google.com/spreadsheet/ccc?key=0Ah_71HHl7qa7dGtvSms3TGpHQU9NU2Y1VmNzUEUteWc
, explanation at
http://lists.wikimedia.org/pipermail/wikitech-l/2011-November/056273.html )


--
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


tylerromeo at gmail

Aug 22, 2012, 1:44 PM

Post #14 of 14 (2453 views)
Permalink
Re: organize a bug triage [In reply to]

> This tool is currently a colossal hack.
XD

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



On Wed, Aug 22, 2012 at 4:26 PM, Sumana Harihareswara <sumanah [at] wikimedia
> wrote:

> On 08/22/2012 03:42 AM, matanya wrote:
> > Hi again,
> >
> > I have started an etherpad here:
> >
> > http://etherpad.wikimedia.org/BugTriage-2012-09
> >
> > Please help improve and comment on date/time/bugs choosen
> >
> > matanya
>
> Thanks for setting this up, Matanya! I've publicized this 5 September
> patch triage to follow a bit more of
> https://www.mediawiki.org/wiki/Bug_Management/Meeting_prep .
>
> Since this is a patch review triage, you might be interested in using
> Rusty Burchfield's (gicode) automated testing of patches for a little
> more information (code at https://github.com/GICodeWarrior/patch-tester
> , 16 August run at
>
> https://docs.google.com/spreadsheet/ccc?key=0Ah_71HHl7qa7dGtvSms3TGpHQU9NU2Y1VmNzUEUteWc
> , explanation at
> http://lists.wikimedia.org/pipermail/wikitech-l/2011-November/056273.html)
>
>
> --
> Sumana Harihareswara
> Engineering Community Manager
> Wikimedia Foundation
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.