Database dump of Bugzilla

List overview All Threads
Download

newer

older

Cry for help from translatewiki.net

Fwd: stat broken?

John Du Hart

3 Mar 2012 3 Mar '12

2:11 a.m.

I'm currently investigating alternative bug tracker and project management software for MediaWiki. To do that I'll be installing some different software on the Labs and importing existing bugs for evaluation by the development team and users. The following software is planned for test: - JIRA <http://www.atlassian.com/software/jira/overview> + Greenhopper + Bonfire - YouTrack <http://www.jetbrains.com/youtrack/> - The Bug Genie <http://www.thebuggenie.com/index.php> - Redmine <http://www.redmine.org/> - ChiliProject <https://www.chiliproject.org/> If you have any suggestions for this list I'd be glad to hear it. Of course, this goes back to the original request. To do this I need a dump of the current Bugzilla install. Is it possible for me to get this and under what conditions? Thank you. -- John

Show replies by date

Amir E. Aharoni

3 Mar 3 Mar

10:12 a.m.

Mantis: http://www.mantisbt.org/ I'm not sure whether it has all the features that Wikimedia projects need, but it does have good internationalization. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com ‪“We're living in pieces, I want to live in peace.” – T. Moore‬ 2012/3/3 John Du Hart <compwhizii(a)gmail.com>om>:

...

David Gerard

11:03 a.m.

On 3 March 2012 09:12, Amir E. Aharoni <amir.aharoni(a)mail.huji.ac.il> wrote:

...

Mantis: http://www.mantisbt.org/ I'm not sure whether it has all the features that Wikimedia projects need, but it does have good internationalization.

Mantis is opaque and hacky. I was put off working on our work installation when, tracing a bug, I found a page which calls a function which calls a function which calls a *page* which calls a function which looks up an enum. Mantis: exemplary PHP. The only reason I haven't installed something else is that all bugtrackers are horrible to install, run or both. We've actually been moving a lot of our bugtracking to pivotaltracker.com, where at least we have active support. tl;dr all software sucks, *especially* bug trackers. - d.

Chad

1:30 p.m.

On Sat, Mar 3, 2012 at 5:03 AM, David Gerard <dgerard(a)gmail.com> wrote:

...

tl;dr all software sucks, *especially* bug trackers.

Agreed. I've never found a bug tracker that I actually *liked* using. Bugzilla happens to be the one I just hate the least. -Chad

K. Peachey

10:18 a.m.

On Sat, Mar 3, 2012 at 11:11 AM, John Du Hart <compwhizii(a)gmail.com> wrote:

...

Haven't we already been around this circle a few times? I seem to remember we even had a couple installed on the WMF servers if I'm not mistaken.

Merlijn van Deen

1:46 p.m.

On 3 March 2012 02:11, John Du Hart <compwhizii(a)gmail.com> wrote:

...

- JIRA <http://www.atlassian.com/software/jira/overview> + Greenhopper + Bonfire - YouTrack <http://www.jetbrains.com/youtrack/> - The Bug Genie <http://www.thebuggenie.com/index.php> - Redmine <http://www.redmine.org/> - ChiliProject <https://www.chiliproject.org/>

Roundup < http://roundup.sourceforge.net/ >, the tracker used for http://bugs.python.org, might also be a candidate to consider. It's one of the bug trackers I find least annoying to use . However, wouldn't adapting Bugzilla to be less annoying be a more sensible option? Converting bugs always is somewhat annoying. Best, Merlijn

John Du Hart

4:53 p.m.

On Sat, Mar 3, 2012 at 7:46 AM, Merlijn van Deen <valhallasw(a)arctus.nl> wrote:

...

However, wouldn't adapting Bugzilla to be less annoying be a more sensible option? Converting bugs always is somewhat annoying.

I agree however there's only so much that can be done to improve Bugzilla. BZ itself is only built to be a bugtracker, however it seems that we are starting to need more features such as scrum (since teams using that now use a different piece of software). -- John

Antoine Musso

8:20 p.m.

Le 03/03/12 02:11, John Du Hart a écrit :

...

Hello John, I beg you to first establish a list of requirements and features we are looking after. You do not want to invest any time installing a software we could dismiss right away just by looking at its specs (see at the bottom of this mail for examples). Let me ask you a question, why do you feel we should move to another bug tracker? Do you think that Bugzilla is missing features we could use? For example, maybe some bug tracker also assist in planning release management. I know Mantis has a nice interface for that. Is that because other tools have a nicer interface? We could probably enhance the Bugzilla one. I am not a huge fan of Bugzilla. It is certainly lagging in terms of neat features lack reporting and ease of navigation between components. But so far, Bugzilla seems to fit our needs nicely. As for testing there is probably no point in loading our existing bugs since close to nobody, beside hexmode, know our bugs well enough to take advantage of it. Instead we can use some demo accounts or just install a version for sandboxing purposes. Both way would be easier than investing time in migrating bugs to some other tracker. If you want some bugs, you can try out Bugzilla JSON interface which is used to generate the release reports. Entry point is: https://bugzilla.wikimedia.org/jsonrpc.cgi Guillaume wrote a blog post about bug tracker, you might want to have a look at it: http://www.gpaumier.org/blog/520_scaling-up-software-development-for-wikime… Find below my comments about the proposed softwares:

...

The following software is planned for test: - JIRA<http://www.atlassian.com/software/jira/overview> + Greenhopper + Bonfire

I guess it was installed on Toolserver just because it was written in Java, a language that River Tarnell like. Anyway, I would dismiss it just because that is a proprietary software.

...

- YouTrack<http://www.jetbrains.com/youtrack/>

Proprietary software as well.

...

- Redmine<http://www.redmine.org/> - ChiliProject<https://www.chiliproject.org/>

The later being a fork of the former. Both are written in ruby which, as far as I know, our operation team do not want to hear about on our production cluster.

...

- The Bug Genie<http://www.thebuggenie.com/index.php>

Demo: http://www.opensourcecms.com/demo/1/259/The+Bug+Genie

...

If you have any suggestions for this list I'd be glad to hear it.

Have a look at mantis http://www.mantisbt.org/ :-) I like it a lot. -- Antoine "hashar" Musso

Merlijn van Deen

9:17 p.m.

On 3 March 2012 20:20, Antoine Musso <hashar+wmf(a)free.fr> wrote:

...

Anyway, I would dismiss it just because that is a proprietary software.

John Du Hart

9:23 p.m.

On Sat, Mar 3, 2012 at 3:17 PM, Merlijn van Deen <valhallasw(a)arctus.nl> wrote:

...

On 3 March 2012 20:20, Antoine Musso <hashar+wmf(a)free.fr> wrote:

Anyway, I would dismiss it just because that is a proprietary software.

I never quite understand this argument. What is wrong with using proprietary software if it's the best software you can use? Or, to turn it around: Why force your developers to work with suboptimal software /just because/ it's open source? Best, Merlijn _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

I agree with that, just because it's proprietary doesn't mean we can't consider it. -- John

David Gerard

11:38 p.m.

On 3 March 2012 20:23, John Du Hart <compwhizii(a)gmail.com> wrote:

...

I agree with that, just because it's proprietary doesn't mean we can't consider it.

It's a seriously strong point in its disfavour. - d.

John Du Hart

11:44 p.m.

On Sat, Mar 3, 2012 at 5:38 PM, David Gerard <dgerard(a)gmail.com> wrote:

...

On 3 March 2012 20:23, John Du Hart <compwhizii(a)gmail.com> wrote:

I agree with that, just because it's proprietary doesn't mean we can't consider it.

It's a seriously strong point in its disfavour. - d. _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

I really don't understand why we'd rather suffer than use a superior proprietary product. -- John

David Gerard

4 Mar 4 Mar

12:25 a.m.

On 3 March 2012 22:44, John Du Hart <compwhizii(a)gmail.com> wrote:

...

I really don't understand why we'd rather suffer than use a superior proprietary product.

https://wikimediafoundation.org/wiki/Values Duplicability down to the infrastructure is considered extremely important, or the free content isn't free. "Open core" fails this test. - d.

David Gerard

12:27 a.m.

On 3 March 2012 23:25, David Gerard <dgerard(a)gmail.com> wrote:

...

On 3 March 2012 22:44, John Du Hart <compwhizii(a)gmail.com> wrote:

...

> I really don't understand why we'd rather suffer than use a superior > proprietary product.

...

https://wikimediafoundation.org/wiki/Values Duplicability down to the infrastructure is considered extremely important, or the free content isn't free. "Open core" fails this test.

(I will note that the Foundation has used nonfree software in infrastructure, e.g. Java before it was freed, Solaris 10 - but only on the way to something free.) - d.

John Du Hart

12:32 a.m.

It's a bug tracker. It's not critical to the operation of a clone and can be replaced. In fact, some teams are using mingle which is a proprietary agile project manager. On Mar 3, 2012 6:26 PM, "David Gerard" <dgerard(a)gmail.com> wrote:

...

On 3 March 2012 22:44, John Du Hart <compwhizii(a)gmail.com> wrote:

I really don't understand why we'd rather suffer than use a superior proprietary product.

https://wikimediafoundation.org/wiki/Values Duplicability down to the infrastructure is considered extremely important, or the free content isn't free. "Open core" fails this test. - d. _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Antoine Musso

12:32 a.m.

John Du Hart wrote:

...

I really don't understand why we'd rather suffer than use a superior proprietary product.

I have been using Linux as a main platform for years and eventually was fed up with the graphical interface. I switched to Mac which, with Aqua, has the best ergonomy around (gnome 3 kde 4 were epic failures). So, indeed, I sometime stop being idealist and get pragmatic. The reason I am dismissing proprietary product is probably because we have been building Wikipedia on top of free software stack for the last 11 years. I clearly remember someone being trolled out of an IRC channel just because he suggested to use some Java software, then non-free software. It might change. But I would prefer having us sticking to FOSS. -- Antoine "hashar" Musso

Chad

3 Mar 3 Mar

11:25 p.m.

On Sat, Mar 3, 2012 at 2:20 PM, Antoine Musso <hashar+wmf(a)free.fr> wrote:

...

As for testing there is probably no point in loading our existing bugs since close to nobody, beside hexmode, know our bugs well enough to take advantage of it. Instead we can use some demo accounts or just install a version for sandboxing purposes. Both way would be easier than investing time in migrating bugs to some other tracker.

I'm going to have to disagree here. There's quite a few of us who've been around here for ages and have more than a passing knowledge of what's in Bugzilla. Then again, I'm fine with the status quo so I'm not volunteering to test anyway. -Chad

John Du Hart

11:45 p.m.

On Sat, Mar 3, 2012 at 5:25 PM, Chad <innocentkiller(a)gmail.com> wrote:

...

Then again, I'm fine with the status quo so I'm not volunteering to test anyway.

Oops too late, already had you down ;) -- John

David Gerard

11:37 p.m.

On 3 March 2012 19:20, Antoine Musso <hashar+wmf(a)free.fr> wrote:

...

Have a look at mantis http://www.mantisbt.org/ :-) I like it a lot.

Have you ever fixed it when it's broken? Anything looks good when it's working, but I've found the experience of trying to bugfix a broken Mantis horrible. If Bugzilla mostly works and its breakages have so far been fixable in-house, that's a *powerful* advantage right there, and it would take really quite strong reasons to move. - d.

Antoine Musso

4 Mar 4 Mar

12:34 a.m.

Le 03/03/12 23:37, David Gerard a écrit : <snip>

...

Have you ever fixed it when it's broken? Anything looks good when it's working, but I've found the experience of trying to bugfix a broken Mantis horrible.

Luckily, I had people fixing my bug reports :-)))))

...

If Bugzilla mostly works and its breakages have so far been fixable in-house, that's a *powerful* advantage right there, and it would take really quite strong reasons to move.

My point. I do not think there is anything better for us than Bugzilla. -- Antoine "hashar" Musso

John Du Hart

12:52 a.m.

I know you don't think that currently however I would like the opportunity to convince you otherwise. On Mar 3, 2012 6:35 PM, "Antoine Musso" <hashar+wmf(a)free.fr> wrote:

...

Le 03/03/12 23:37, David Gerard a écrit : <snip>

Have you ever fixed it when it's broken? Anything looks good when it's working, but I've found the experience of trying to bugfix a broken Mantis horrible.

Luckily, I had people fixing my bug reports :-))))) If Bugzilla mostly works and its breakages have so far been fixable

in-house, that's a *powerful* advantage right there, and it would take really quite strong reasons to move.

My point. I do not think there is anything better for us than Bugzilla. -- Antoine "hashar" Musso ______________________________**_________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<https://lists.…

David Gerard

1:08 a.m.

On 3 March 2012 23:52, John Du Hart <compwhizii(a)gmail.com> wrote:

...

On Mar 3, 2012 6:35 PM, "Antoine Musso" <hashar+wmf(a)free.fr> wrote:

...

> My point. I do not think there is anything better for us than Bugzilla.

...

I know you don't think that currently however I would like the opportunity to convince you otherwise.

Which one are you involved with? - d.

John Du Hart

1:48 a.m.

I don't understand the question. Are you implying that I have some sort of relationship with one of these vendors? If that's the case then I'd like to inform you that's not the case. My motive here is giving developers and users access to better tools so that we can make a better product. On Mar 3, 2012 7:08 PM, "David Gerard" <dgerard(a)gmail.com> wrote:

...

On 3 March 2012 23:52, John Du Hart <compwhizii(a)gmail.com> wrote:

On Mar 3, 2012 6:35 PM, "Antoine Musso" <hashar+wmf(a)free.fr> wrote:

> My point. I do not think there is anything better for us than Bugzilla.

I know you don't think that currently however I would like the

opportunity

to convince you otherwise.

Which one are you involved with? - d. _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Antoine Musso

12:31 p.m.

John Du Hart wrote:

...

Antoine wrote:

My point. I do not think there is anything better for us than Bugzilla.

I know you don't think that currently however I would like the opportunity to convince you otherwise.

I would love to be proven wrong! As time allow, I will likely help you in your quest to find us a better bug tracker 8-) -- Antoine "hashar" Musso

Chad

3 Mar 3 Mar

11:50 p.m.

On Sat, Mar 3, 2012 at 2:20 PM, Antoine Musso <hashar+wmf(a)free.fr> wrote:

...

I beg you to first establish a list of requirements and features we are looking after. You do not want to invest any time installing a software we could dismiss right away just by looking at its specs (see at the bottom of this mail for examples).

While we're talking about requirements--let me say that something I'd ike to see if we move bugtrackers is LDAP support (does BZ have this?). We're moving more and more tech services to LDAP, so it would make sense to integrate our bugtracker there as well. -Chad

Chad

11:51 p.m.

On Sat, Mar 3, 2012 at 5:50 PM, Chad <innocentkiller(a)gmail.com> wrote:

...

On Sat, Mar 3, 2012 at 2:20 PM, Antoine Musso <hashar+wmf(a)free.fr> wrote:

Answered my own question--yes BZ does support LDAP out of the box, no plugins required. -Chad

Tomasz Finc

11:09 p.m.

Didn't robla do this same analysis about a year ago? Are his notes up somewhere so that we don't waste time on solutions that simply won't work. Finding those could make this go way faster. Adjusted for whatever has changed in the projects since his review of course. 02-03-2012 17:11 użytkownik "John Du Hart" <compwhizii(a)gmail.com> napisał:

...

John Du Hart

11:19 p.m.

On Mar 3, 2012 2:20 PM, "Antoine Musso" <hashar <hashar%2Bwmf@free.fr>+<hashar%2Bwmf@free.fr

...

wmf <hashar%2Bwmf@free.fr>@ <hashar%2Bwmf@free.fr>free.fr<hashar%2Bwmf@free.fr>

...

wrote:

...

Le 03/03/12 02:11, John Du Hart a écrit : > I'm currently investigating alternative bug tracker and project

management

...

software for MediaWiki. To do that I'll be installing some different software on the Labs and importing existing bugs for evaluation by the development team and users.

Hello John, I beg you to first establish a list of requirements and features we are

looking after. You do not want to invest any time installing a software we could dismiss right away just by looking at its specs (see at the bottom of this mail for examples).

...

Fair enough. I think what I'm looking for is a bug tracker that is more easier to use for both developers and users. I would also like tools that allow us to better visualize progress on bugs and what's fixed or needed for a released. Finally an API that doesn't suck would be nice

...

Let me ask you a question, why do you feel we should move to another bug

tracker?

...

Do you think that Bugzilla is missing features we could use? For example, maybe some bug tracker also assist in planning release

management. I know Mantis has a nice interface for that.

...

Is that because other tools have a nicer interface? We could probably

enhance the Bugzilla one.

...

> I am not a huge fan of Bugzilla. It is certainly lagging in terms of neat features lack reporting and ease of navigation between components. But so far, Bugzilla seems to fit our needs nicely.

...

But I'm sure we could do better!

...

As for testing there is probably no point in loading our existing bugs

since close to nobody, beside hexmode, know our bugs well enough to take advantage of it. Instead we can use some demo accounts or just install a version for sandboxing purposes. Both way would be easier than investing time in migrating bugs to some other tracker.

...

I disagree. I think that if the software supports an importer it wouldn't hurt to use it for the demo.

...

If you want some bugs, you can try out Bugzilla JSON interface which is

used to generate the release reports. Entry point is: > https:// <https://bugzilla.wikimedia.org/jsonrpc.cgi

...

bugzilla.wikimedia.org <https://bugzilla.wikimedia.org/jsonrpc.cgi>/<https://bugzilla.wikimedia.org/jsonrpc.cgi

...

jsonrpc.cgi <https://bugzilla.wikimedia.org/jsonrpc.cgi

...

Again most of the software supports an import via a database dump so I'd rather use that.

...

Guillaume wrote a blog post about bug tracker, you might want to have a

look at it: > http://<http://www.gpaumier.org/blog/520_scaling-up-software-development-for-wikimedia-websites-tools/

...

www.gpaumier.org<http://www.gpaumier.org/blog/520_scaling-up-software-de…

...

/blog/520_scaling-up-software-development-for-<http://www.gpaumier.org/blog/520_scaling-up-software-development-for-wikimedia-websites-tools/

...

wikimedia<http://www.gpaumier.org/blog/520_scaling-up-software-developme…

...

-websites-tools/<http://www.gpaumier.org/blog/520_scaling-up-software-development-for-wikimedia-websites-tools/

...

Interesting. Again, it seems we're in agreement for the need of a better project management tool.

...

> Find below my comments about the proposed softwares:

...

>> The following software is planned for test: >

...

>> - JIRA<http:// <http://www.atlassian.com/software/jira/overview

...

www.atlassian.com <http://www.atlassian.com/software/jira/overview

...

/software/ <http://www.atlassian.com/software/jira/overview>jira<http://www.atlassian.com/software/jira/overview

...

/overview <http://www.atlassian.com/software/jira/overview>

...

>> + Greenhopper + Bonfire

...

> I guess it was installed on Toolserver just because it was written in Java, a language that River Tarnell like. > Anyway, I would dismiss it just because that is a proprietary software.

...

>> - YouTrack<http:// <http://www.jetbrains.com/youtrack/

...

www.jetbrains.com <http://www.jetbrains.com/youtrack/>/<http://www.jetbrains.com/youtrack/

...

youtrack <http://www.jetbrains.com/youtrack/>/<http://www.jetbrains.com/youtrack/

...

> Proprietary software as well. Like I replied earlier, this is not a major concern.

...

>> - Redmine<http:// <http://www.redmine.org/>www.redmine.org/<http://www.redmine.org/

...

>> - ChiliProject<https:// <https://www.chiliproject.org/

...

www.chiliproject.org/ <https://www.chiliproject.org/>

...

> The later being a fork of the former. Both are written in ruby which, as far as I know, our operation team do not want to hear about on our production cluster.

...

Fair enough.

...

> > - The Bug Genie<http:// <http://www.thebuggenie.com/index.php

...

www.thebuggenie.com <http://www.thebuggenie.com/index.php>/<http://www.thebuggenie.com/index.php

...

index.php <http://www.thebuggenie.com/index.php>

...

> Demo: > http:// <http://www.opensourcecms.com/demo/1/259/The+Bug+Genie

...

www.opensourcecms.com<http://www.opensourcecms.com/demo/1/259/The+Bug+Ge…

...

/demo/1/259/The+Bug+Genie<http://www.opensourcecms.com/demo/1/259/The+Bug+Genie

...

>> If you have any suggestions for this list I'd be glad to hear it.

...

> Have a look at mantis http:// <http://www.mantisbt.org/>www.mantisbt.org/<http://www.mantisbt.org/>:-) I like it a lot.

...

Sure. > -- > Antoine "hashar" Musso

...

> _______________________________________________ > Wikitech-l mailing list > Wikitech <Wikitech-l@lists.wikimedia.org>-l@<Wikitech-l@lists.wikimedia.org

...

lists.wikimedia.org <Wikitech-l(a)lists.wikimedia.org

...

> https:// <https://lists.wikimedia.org/mailman/listinfo/wikitech-l

...

lists.wikimedia.org<https://lists.wikimedia.org/mailman/listinfo/wikitec…

...

/mailman/ <https://lists.wikimedia.org/mailman/listinfo/wikitech-l>listinfo<https://lists.wikimedia.org/mailman/listinfo/wikitech-l

...

/ <https://lists.wikimedia.org/mailman/listinfo/wikitech-l>wikitech<https://lists.wikimedia.org/mailman/listinfo/wikitech-l

...

-l <https://lists.wikimedia.org/mailman/listinfo/wikitech-l

...

mah＠wikimedia.org

4 Mar 4 Mar

4:30 a.m.

John Du Hart <compwhizii(a)gmail.com> writes:

...

I'm not about to argue for the user-friendliness of Bugzilla or visualization that it offers. However, I have used the API extensively and, while I do agree that there are areas it could be improved, I've found it useful for most things. Hack-ability is a big benefit here. Lots of other people use Bugzilla and adapt it to their needs. Some of those changes get incorporated into the core. Mozilla, for instance, created MediaWiki integration that might help with visualization: http://lawrencemandel.com/2012/02/23/embed-bugzilla-data-in-wikimo-pages/ (This was later disabled because of the load on Bugzilla, but I think it is a start. See <https://bugzilla.mozilla.org/731672>.) And the Mozilla has certainly shown that Bugzilla's UI (at least for entering bugs, which is the biggest pain point for for new users) can be made better. I don't think Bugzilla is the best it could possibly be. But, I do think there is the problem of known pain (Bugzilla) versus the unknown pain that will come with learning a new system and then adapting to its quirks and inadequacies. I would rather use the energy to adapt Bugzilla to our needs.

...

Proprietary software as well.

Like I replied earlier, this is not a major concern.

I think you'll find quite a lot of resistance from me on this point. -- Mark A. Hershberger Bugmeister Wikimedia Foundation mah(a)wikimedia.org

Platonides

5 Mar 5 Mar

1:10 a.m.

On 04/03/12 04:30, Mark A. Hershberger wrote:

...

But, I do think there is the problem of known pain (Bugzilla) versus the unknown pain that will come with learning a new system and then adapting to its quirks and inadequacies. I would rather use the energy to adapt Bugzilla to our needs.

That's a very good point to take into account. We currently know our way through bugzilla. I have met bug trackers that, although they may have many bells and whistles, I found hard to do simple operations like... reporting a bug.

Daniel Barrett

4:39 p.m.

Just a quick note from an unbiased observer who loves MediaWiki and open-source... Proprietary or not, Atlassian Jira is the best bug-tracker I have ever used, out of about 10 systems. - Very configurable - You can create very simple bug forms for nontechnical users - Plug-in architecture for developing your own features & modifying app behavior (see https://plugins.atlassian.com/) - Helpful reporting capabilities that are easy to use - Its database schema is pretty understandable so you can extract data directly - The web interface doesn't do any stupid tricks that break in different browsers If you're considering another bug-tracker, Jira is worth a look. (I have no affiliation with the product or the vendor, except as an end-user.) DanB

Rob Lanphier

4 Mar 4 Mar

3:21 a.m.

Hi John, I'm happy that you're looking at this, because I can't say that I'm thrilled with Bugzilla, and I'd be happy to see a better alternative to it. However, I also kinda agree with Chad: it's not that I love Bugzilla, but rather we haven't yet found a system that's better enough to invest in a migration. That's been the state of things for so long that it's very easy to get cynical about it. That said, I'm keeping an open mind, and I'm intrigued by one of your suggestions (Bug Genie). More on that in a bit. One requirement I would like to place on a new system, should we go there, is that it support Wikimedia SUL in some form. I realize that Bugzilla doesn't support this, but the point behind this requirement would be that if we're going to go through a painful migration, integration with our existing login system needs to be one of the benefits. It might mean that this project come behind some form of OpenID provider support on the Wikimedia cluster. More inline... On Fri, Mar 2, 2012 at 5:11 PM, John Du Hart <compwhizii(a)gmail.com> wrote:

...

I've got a lot of experience with JIRA that I'm happy to share offlist. Since this has partially devolved into a discussion about open vs proprietary, I think you should read this: http://www.atlassian.com/licensing/license ...and not install it until you have. There will be a test ;-) Generally, it's going to take a lot to convince me that a proprietary solution is going to work for us.

...

- YouTrack <http://www.jetbrains.com/youtrack/> - The Bug Genie <http://www.thebuggenie.com/index.php> - Redmine <http://www.redmine.org/> - ChiliProject <https://www.chiliproject.org/>

Redmine is the one that was the frontrunner the last evaluation we did in 2010: http://www.mediawiki.org/wiki/Tracker/PM_tool There's possibly some other stuff to look at on the 2010 list. As I alluded to, I'm intrigued by The Bug Genie. Looks like it's PHP-based open source, under active development for 10 years, and that they've put some thought into the UI. I don't think that one came up in our last eval, but it probably should have. I'd encourage you to nudge that one higher on your list.

...

Of course, this goes back to the original request. To do this I need a dump of the current Bugzilla install. Is it possible for me to get this and under what conditions? Thank you.

There's some confidential information in there, so possibly an NDA. I'll talk to Sumana on Monday about this. One thing that I would ask of you, though, is to be mindful of our community's actual capacity for disruptive change and development/operations capacity in general. The reason why we dropped this project back in 2010 was that it became clear that we were trying to do too many things in parallel, and not doing any of those things well. While WMF has more capacity, and you're helping out by volunteering this work, we still might not have capacity for this project. Even if you do a lot of the work, it will be both a disruption for others, as well as a fair amount of work for others. Given we're smack dab in the middle of an incredibly disruptive change (migrating from SVN to Git), it seems like this might be the wrong time to do anything more than experiments. So, that's not to say "don't evaluate other systems", but just be mindful that success might still mean waiting until late 2012 or even 2013 for the project to really begin in earnest. If you're ok with that, then I say "great"! If that sounds like way too long to wait after doing a lot of work, then I'd caution against starting. Rob

mah＠wikimedia.org

4:37 a.m.

Rob Lanphier <robla(a)wikimedia.org> writes:

...

One requirement I would like to place on a new system, should we go there, is that it support Wikimedia SUL in some form. I realize that Bugzilla doesn't support this, but the point behind this requirement would be that if we're going to go through a painful migration, integration with our existing login system needs to be one of the benefits. It might mean that this project come behind some form of OpenID provider support on the Wikimedia cluster.

Bugzilla does allow you to add in your own authentication system, so I would say it supports it "in some form". But yes, SUL should be high on the list. Mark. -- Mark A. Hershberger Bugmeister Wikimedia Foundation mah(a)wikimedia.org

Bináris

12:49 p.m.

2012/3/4 Mark A. Hershberger <mah(a)wikimedia.org>

...

Bugzilla does allow you to add in your own authentication system, so I would say it supports it "in some form". But yes, SUL should be high on the list.

It would be great to use SUL. Care should be taken that by this time e-mail addresses were used instead of user name, and at integration of old data into the new system these addresses should not be publicly connected to user names. -- Bináris

Thomas Gries

6 Mar 6 Mar

9:42 a.m.

Regarding JIRA, allow me to report my experience with it: JIRA is slow. I would _not_ recommend MediaWiki's change from Bugzilla to JIRA.

Petr Bena

9:58 a.m.

Instead of changing sw we should improve the bugzilla, list of things I would like to change * Login with SUL instead of separated username * Improve the rss feed, let users create a custom rss On Tue, Mar 6, 2012 at 9:42 AM, Thomas Gries <mail(a)tgries.de> wrote:

...

Regarding JIRA, allow me to report my experience with it: JIRA is slow. I would _not_ recommend MediaWiki's change from Bugzilla to JIRA. _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Thomas Gries

10:01 a.m.

Am 06.03.2012 09:58, schrieb Petr Bena:

...

Instead of changing sw we should improve the bugzilla, list of things I would like to change * Login with SUL instead of separated username

...

* Improve the rss feed, let users create a custom rss

Platonides

7:16 p.m.

On 06/03/12 09:58, Petr Bena wrote:

...

Instead of changing sw we should improve the bugzilla, list of things I would like to change

One way could be to provide an alternative bugzilla interface. For which it having a sample db dump would be nice.

Antoine Musso

7 Mar 7 Mar

2:39 p.m.

Platonides write:

...

One way could be to provide an alternative bugzilla interface. For which it having a sample db dump would be nice.

Maybe it could be done using the JSON RPC? :-) -- Antoine "hashar" Musso

Platonides

9:33 p.m.

On 07/03/12 14:39, Antoine Musso wrote:

...

Platonides write:

One way could be to provide an alternative bugzilla interface. For which it having a sample db dump would be nice.

Maybe it could be done using the JSON RPC? :-)

Does it allow to impersonate the user? PS: http://www.bugzilla.org/docs/4.2/en/html/api/Bugzilla/WebService/Server/JSO… recommends XMLRPC over JSON RPC.

Max Semenik

4 Mar 4 Mar

12:27 p.m.

On 04.03.2012, 6:21 Rob wrote:

...

Hi John,

...

I'm happy that you're looking at this, because I can't say that I'm thrilled with Bugzilla, and I'd be happy to see a better alternative to it. However, I also kinda agree with Chad: it's not that I love Bugzilla, but rather we haven't yet found a system that's better enough to invest in a migration. That's been the state of things for so long that it's very easy to get cynical about it. That said, I'm keeping an open mind, and I'm intrigued by one of your suggestions (Bug Genie). More on that in a bit.

Yes, (un)?fortunately, current status quo looks extremely hard to change. However, there's one big reason for a change: although Bugzilla is tolerable for us developers, it's EXTREMELY unfriendly to non-technical mortal humans who are supposed to submit bugs for us to work on.

...

Actually, OpenID is closer than one might anticipate, as it's on my RfP. -- Best regards, Max Semenik ([[User:MaxSem]])

Merlijn van Deen

1:27 p.m.

On 4 March 2012 12:27, Max Semenik <maxsem.wiki(a)gmail.com> wrote:

...

However, there's one big reason for a change: although Bugzilla is tolerable for us developers, it's EXTREMELY unfriendly to non-technical mortal humans who are supposed to submit bugs for us to work on. Keep in mind this is mainly an interface issue. For instance, the mozilla

bugzilla [1] is much more convenient to use, at least from the 'file a bug'-perspective. It's inconvenient you have to register to see the bug submit form, but the general workflow is as follows: (1) click 'file a bug' (2) get a list of possible products to file a bug for (3) enter a summary, with a forced search for possibly related issues (4) click 'this issue is not listed' (5) fill in the following form: http://i.imgur.com/RIUNr.png As such, I think this process can be improved a lot, even while staying with bugzilla. Best, Merlijn [1] https://bugzilla.mozilla.org/

David Schoonover

21 May 21 May

7:56 p.m.

I'm a little late to this as well, but I didn't see any mention of Trac ( http://trac.edgewall.org/ ) in this thread. It has several things in its favor: - Open source - Python - Great community - Easily hackable, very flexible, and as a result... - Tons of open-source plugins for all your needs At the last place I worked, we wanted a whiteboard-style SCRUM tool for laying out the backlog and allocating it into buckets. We wrote and released a plugin for Trac: - https://github.com/clearspring/tracboard I've always felt that when it comes to bug-tracking and project-management software, every org is different, and as a result, it often makes sense to roll your own to reflect your workflow. I think the best projects are the ones that make it easiest to do this without reinventing the wheel. Trac's ease of customizability is a big plus. -- David Schoonover dsc(a)wikimedia.org On Mar 3, 2012, at 6:21 PM, Rob Lanphier wrote:

...

- YouTrack <http://www.jetbrains.com/youtrack/> - The Bug Genie <http://www.thebuggenie.com/index.php> - Redmine <http://www.redmine.org/> - ChiliProject <https://www.chiliproject.org/>

Of course, this goes back to the original request. To do this I need a dump of the current Bugzilla install. Is it possible for me to get this and under what conditions? Thank you.

Erik Moeller

19 Mar 19 Mar

6:30 p.m.

On Fri, Mar 2, 2012 at 5:11 PM, John Du Hart <compwhizii(a)gmail.com> wrote:

...

Hi John, belatedly: If you have time, it would be nice if you could set up a couple of agile/scrum focused PM tools for a spin as well. We're currently using Mingle (proprietary) and it would be nice to give open source solutions a fair shot. Examples: * http://www.icescrum.org/ * http://wholemeal.co.nz/projects/fulcrum.html [still early days, but looks promising] * http://scrumdo.org/ * http://kunagi.org/ (If someone has experience with these or other agile PM tools, please weigh in, especially insofar as user experience and integration with the overall development workflow - bug tracker, etc. - is concerned.) Cheers, Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

4356

days inactive

4435

days old

wikitech-l@lists.wikimedia.org

Manage subscription

43 comments

18 participants

tags (0)

participants (18)

Amir E. Aharoni
Antoine Musso
Bináris
Chad
Daniel Barrett
David Gerard
David Schoonover
Erik Moeller
John Du Hart
K. Peachey
mah＠wikimedia.org
Max Semenik
Merlijn van Deen
Petr Bena
Platonides
Rob Lanphier
Thomas Gries
Tomasz Finc