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