Hey all,
Now that we're on a more regular deployment schedule, staying on top of the blocking bugs and deviding lists into smaller, more managable chunks, is more and more important.
For that reason I put together a quick tool:
https://toolserver.org/~krinkle/wmfBugZillaPortal/
It is already becoming clear that there is a lot of stuff left behind from past versions. We should probably start moving stuff to later verisons and keep an eye on it more regularly.
-- Krinkle
On May 3, 2012, at 5:28 AM, Krinkle wrote:
Hey all,
Now that we're on a more regular deployment schedule, staying on top of the blocking bugs and deviding lists into smaller, more managable chunks, is more and more important.
For that reason I put together a quick tool:
https://toolserver.org/~krinkle/wmfBugZillaPortal/
It is already becoming clear that there is a lot of stuff left behind from past versions. We should probably start moving stuff to later verisons and keep an eye on it more regularly.
-- Krinkle
This tool (among others) is in source control and running on toolserver from trunk:
* https://svn.toolserver.org/svnroot/krinkle/trunk/wmfBugZillaPortal/ * https://fisheye.toolserver.org/browse/krinkle/trunk/wmfBugZillaPortal
-- Krinkle
On Wed, May 2, 2012 at 8:28 PM, Krinkle krinklemail@gmail.com wrote:
Oooo, nice, thanks for this Krinkle!
Rob
Krinkle wrote:
Now that we're on a more regular deployment schedule, staying on top of the blocking bugs and deviding lists into smaller, more managable chunks, is more and more important.
For that reason I put together a quick tool:
https://toolserver.org/~krinkle/wmfBugZillaPortal/
It is already becoming clear that there is a lot of stuff left behind from past versions. We should probably start moving stuff to later verisons and keep an eye on it more regularly.
Nice job on this. :-)
This appears to mostly be an index of Bugzilla search queries. Do you know if there's been any progress on making the Bugzilla database available in a replicated form (on the Toolserver or Wikimedia Labs or elsewhere)? Direct SQL access would allow for much more flexible reports.
MZMcBride
On Fri, May 4, 2012 at 8:14 AM, MZMcBride z@mzmcbride.com wrote:
Nice job on this. :-)
This appears to mostly be an index of Bugzilla search queries. Do you know if there's been any progress on making the Bugzilla database available in a replicated form (on the Toolserver or Wikimedia Labs or elsewhere)? Direct SQL access would allow for much more flexible reports.
Last I heard (a while ago), This planning/idea has had to be halted (temporarily?) because we now store private data in the system (see: Security Product/Component combo to name one location), also the db resided on the "private db" box/cluster/combo/delity which isn't desired to be replicated over to the TS for various reasons.
Le 04/05/12 00:14, MZMcBride a écrit :
This appears to mostly be an index of Bugzilla search queries. Do you know if there's been any progress on making the Bugzilla database available in a replicated form (on the Toolserver or Wikimedia Labs or elsewhere)? Direct SQL access would allow for much more flexible reports.
One could most probably write a ton of reports using the JSON API:
https://bugzilla.wikimedia.org/jsonrpc.cgi
Doc: https://bugzilla.wikimedia.org/docs/en/html/api/Bugzilla/WebService/Server/J...
On Fri, May 4, 2012 at 7:29 AM, Antoine Musso hashar+wmf@free.fr wrote:
One could most probably write a ton of reports using the JSON API:
https://bugzilla.wikimedia.org/jsonrpc.cgi
Doc:
https://bugzilla.wikimedia.org/docs/en/html/api/Bugzilla/WebService/Server/J...
Yep, however currently I'm hardcoding [1] the versions and milestones because the API of BugZilla < 4.2 does not expose them (see NOTES[2]).
After bugzilla.wikimedia.org is upgraded to 4.2 I'll let it grab the versions and milestones dynamically from the API instead, and maybe add some custom lists as well. That way things won't break if a version or milestone is renamed and new ones are automatically added.
-- Krinkle
[1] https://github.com/Krinkle/ts-krinkle-wmfBugZillaPortal/blob/c5611c966112d1e...
[2] https://github.com/Krinkle/ts-krinkle-wmfBugZillaPortal/blob/553de37ce541b32...
On 05/07/2012 04:39 AM, Krinkle wrote:
On Fri, May 4, 2012 at 7:29 AM, Antoine Musso hashar+wmf@free.fr wrote:
One could most probably write a ton of reports using the JSON API:
https://bugzilla.wikimedia.org/jsonrpc.cgi
Doc:
https://bugzilla.wikimedia.org/docs/en/html/api/Bugzilla/WebService/Server/J...
Yep, however currently I'm hardcoding [1] the versions and milestones because the API of BugZilla < 4.2 does not expose them (see NOTES[2]).
After bugzilla.wikimedia.org is upgraded to 4.2 I'll let it grab the versions and milestones dynamically from the API instead, and maybe add some custom lists as well. That way things won't break if a version or milestone is renamed and new ones are automatically added.
-- Krinkle
[1] https://github.com/Krinkle/ts-krinkle-wmfBugZillaPortal/blob/c5611c966112d1e...
[2] https://github.com/Krinkle/ts-krinkle-wmfBugZillaPortal/blob/553de37ce541b32...
Is there already a ticket somewhere in RT or the like re upgrading bugzilla.wikimedia.org to 4.2?
Also, http://www.gamasutra.com/view/feature/131191/how_funcom_squashed_bugs_with_.... was brought to my attention - yet another case study of how/why to adjust Bugzilla UI to a community's needs.
Sumana Harihareswara wrote:
Is there already a ticket somewhere in RT or the like re upgrading bugzilla.wikimedia.org to 4.2?
https://bugzilla.wikimedia.org/show_bug.cgi?id=33158
MZMcBride
wikitech-l@lists.wikimedia.org