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.
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@gmail.com:
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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 3 March 2012 09:12, Amir E. Aharoni amir.aharoni@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.
On Sat, Mar 3, 2012 at 5:03 AM, David Gerard dgerard@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
On Sat, Mar 3, 2012 at 11:11 AM, John Du Hart compwhizii@gmail.com wrote:
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:
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.
On 3 March 2012 02:11, John Du Hart compwhizii@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
On Sat, Mar 3, 2012 at 7:46 AM, Merlijn van Deen valhallasw@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).
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).
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-wikimed...
Find below my comments about the proposed softwares:
The following software is planned for test:
- 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.
On 3 March 2012 20:20, Antoine Musso hashar+wmf@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
On Sat, Mar 3, 2012 at 3:17 PM, Merlijn van Deen valhallasw@arctus.nl wrote:
On 3 March 2012 20:20, Antoine Musso hashar+wmf@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@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.
On 3 March 2012 20:23, John Du Hart compwhizii@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.
On Sat, Mar 3, 2012 at 5:38 PM, David Gerard dgerard@gmail.com wrote:
On 3 March 2012 20:23, John Du Hart compwhizii@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@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.
On 3 March 2012 22:44, John Du Hart compwhizii@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.
On 3 March 2012 23:25, David Gerard dgerard@gmail.com wrote:
On 3 March 2012 22:44, John Du Hart compwhizii@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.
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@gmail.com wrote:
On 3 March 2012 22:44, John Du Hart compwhizii@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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.
On Sat, Mar 3, 2012 at 2:20 PM, Antoine Musso hashar+wmf@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
On Sat, Mar 3, 2012 at 5:25 PM, Chad innocentkiller@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 ;)
On 3 March 2012 19:20, Antoine Musso hashar+wmf@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.
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.
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@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@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 3 March 2012 23:52, John Du Hart compwhizii@gmail.com wrote:
On Mar 3, 2012 6:35 PM, "Antoine Musso" hashar+wmf@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.
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@gmail.com wrote:
On 3 March 2012 23:52, John Du Hart compwhizii@gmail.com wrote:
On Mar 3, 2012 6:35 PM, "Antoine Musso" hashar+wmf@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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-)
On Sat, Mar 3, 2012 at 2:20 PM, Antoine Musso hashar+wmf@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
On Sat, Mar 3, 2012 at 5:50 PM, Chad innocentkiller@gmail.com wrote:
On Sat, Mar 3, 2012 at 2:20 PM, Antoine Musso hashar+wmf@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.
Answered my own question--yes BZ does support LDAP out of the box, no plugins required.
-Chad
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@gmail.com napisał:
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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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.frfree.frhashar%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:
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.orghttp://www.gpaumier.org/blog/520_scaling-up-software-development-for-wikimedia-websites-tools/ /blog/520_scaling-up-software-development-for-http://www.gpaumier.org/blog/520_scaling-up-software-development-for-wikimedia-websites-tools/ wikimediahttp://www.gpaumier.org/blog/520_scaling-up-software-development-for-wikimedia-websites-tools/ -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/overviewjirahttp://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.comhttp://www.opensourcecms.com/demo/1/259/The+Bug+Genie /demo/1/259/The+Bug+Geniehttp://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@lists.wikimedia.org
https:// https://lists.wikimedia.org/mailman/listinfo/wikitech-l
lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/wikitech-l /mailman/ https://lists.wikimedia.org/mailman/listinfo/wikitech-llistinfohttps://lists.wikimedia.org/mailman/listinfo/wikitech-l / https://lists.wikimedia.org/mailman/listinfo/wikitech-lwikitechhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l -l https://lists.wikimedia.org/mailman/listinfo/wikitech-l
John Du Hart compwhizii@gmail.com writes:
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
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.
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.
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
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@gmail.com wrote:
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
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
Rob Lanphier robla@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.
2012/3/4 Mark A. Hershberger mah@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.
Regarding JIRA, allow me to report my experience with it:
JIRA is slow.
I would _not_ recommend MediaWiki's change from Bugzilla to JIRA.
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@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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/JSON... recommends XMLRPC over JSON RPC.
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.
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.
Actually, OpenID is closer than one might anticipate, as it's on my RfP.
On 4 March 2012 12:27, Max Semenik maxsem.wiki@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
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@wikimedia.org
On Mar 3, 2012, at 6:21 PM, Rob Lanphier 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.
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@gmail.com wrote:
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
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
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Fri, Mar 2, 2012 at 5:11 PM, John Du Hart compwhizii@gmail.com wrote:
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:
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
wikitech-l@lists.wikimedia.org