<br><br><div class="gmail_quote">2011/8/7 Maciej Bliziński <span dir="ltr"><<a href="mailto:maciej@opencsw.org">maciej@opencsw.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2011/8/6 Peter FELECAN <<a href="mailto:pfelecan@opencsw.org">pfelecan@opencsw.org</a>>:<br>
<div class="im">> Maciej Bliziński <<a href="mailto:maciej@opencsw.org">maciej@opencsw.org</a>> writes:<br>
><br>
>> Mantis is not written for<br>
>> the number of projects that we have. It is meant to handle a two digit<br>
>> number of projects, and we have a four digit one<br>
><br>
> Debian is using a BTS for a bigger magnitude, isn't it? What about using<br>
> their system? Just a thought...<br>
<br>
</div>Debian BTS / Debbugs has indeed work with a large number of packages,<br>
and the sources are available[1].  However, if you the summary on<br>
Wikipedia, it it's an email based system, and although you can search<br>
and view bugs from a web interface, the main input and output is<br>
email.  What I like about it, is that there is the reportbug utility<br>
which drives the bug reporting process.  Overall, it feels dated.<br>
<br>
Another system that is in use, is Bugzilla. It's used by e. g. Red<br>
Hat.  It is a web based system, and if it has an email input, it's<br>
only an addon.<br>
<br>
In the case of a packaging project, the main consideration is this:<br>
the user who reports the issue, has a rough idea against which package<br>
the issue needs to be filed. It still can be fuzzy in the case of<br>
split packages, e.g. cups vs cupsd vs cupsclient, but let's assume<br>
that the user knows which package the bugs belongs to.  What mantis<br>
does for us, is that it shows the list of packages to the user, and<br>
knows which maintainer is assigned to which package.  This is a great<br>
feature.  I talked once to a Gentoo developer and their bugzilla<br>
installation.  I learned that their bugzilla does not have that<br>
mapping, and a human is necessary for the bug to be routed to the<br>
right person.  In this light, Mantis does a pretty good job for us,<br>
and if we look for a new system, we need to make sure that it has an<br>
easy user interface to map from packages to maintainers.  That also<br>
requires having some form of abstraction that we can use to represent<br>
packages. In Mantis it's projects, but in a different bug tracker it<br>
could be a different abstraction, e.g. a component or simply a tag.<br>
<br>
I'm with Ben on that I'd rather look for a way to restore the<br>
catalog→mantis synchronization, the cheaper the better, and go from<br>
there.  I don't want discourage anyone from looking for a better<br>
bugtracker - if we had a better bugtracker, I'm all for it! There<br>
already is a wiki page about the topic[3], so if anyone makes<br>
progress, I'd encourage them to share it.<br><br></blockquote><div> </div></div>I see that progress has been made on moving to Jira. Sounds good to me. Jira has the idea of a 'project leader' that can be the default assignee per project (or you can configure someone else as the default assignee, or an abstract role user). The wiki page was last updated in September 2010 though, is this still 'the plan'? <div>
<br></div><div>Given the plan looks to be to switch to Jira, with Crowd as a single sign-on solution, might as well grab Fisheye as well for browsing code and linking to Jira issues. Atlassian do their community licence for Fisheye as well. </div>
<div><br></div>