On Tue, Aug 16, 2011 at 04:40, Jesse Reynolds <[email protected]> wrote:
> > > 2011/8/7 Maciej Bliziński <[email protected]> > >> 2011/8/6 Peter FELECAN <[email protected]>: >> > Maciej Bliziński <[email protected]> writes: >> > >> >> Mantis is not written for >> >> the number of projects that we have. It is meant to handle a two digit >> >> number of projects, and we have a four digit one >> > >> > Debian is using a BTS for a bigger magnitude, isn't it? What about using >> > their system? Just a thought... >> >> Debian BTS / Debbugs has indeed work with a large number of packages, >> and the sources are available[1]. However, if you the summary on >> Wikipedia, it it's an email based system, and although you can search >> and view bugs from a web interface, the main input and output is >> email. What I like about it, is that there is the reportbug utility >> which drives the bug reporting process. Overall, it feels dated. >> >> Another system that is in use, is Bugzilla. It's used by e. g. Red >> Hat. It is a web based system, and if it has an email input, it's >> only an addon. >> >> In the case of a packaging project, the main consideration is this: >> the user who reports the issue, has a rough idea against which package >> the issue needs to be filed. It still can be fuzzy in the case of >> split packages, e.g. cups vs cupsd vs cupsclient, but let's assume >> that the user knows which package the bugs belongs to. What mantis >> does for us, is that it shows the list of packages to the user, and >> knows which maintainer is assigned to which package. This is a great >> feature. I talked once to a Gentoo developer and their bugzilla >> installation. I learned that their bugzilla does not have that >> mapping, and a human is necessary for the bug to be routed to the >> right person. In this light, Mantis does a pretty good job for us, >> and if we look for a new system, we need to make sure that it has an >> easy user interface to map from packages to maintainers. That also >> requires having some form of abstraction that we can use to represent >> packages. In Mantis it's projects, but in a different bug tracker it >> could be a different abstraction, e.g. a component or simply a tag. >> >> I'm with Ben on that I'd rather look for a way to restore the >> catalog→mantis synchronization, the cheaper the better, and go from >> there. I don't want discourage anyone from looking for a better >> bugtracker - if we had a better bugtracker, I'm all for it! There >> already is a wiki page about the topic[3], so if anyone makes >> progress, I'd encourage them to share it. >> >> > 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'? > > 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. > if we really want to go commercial as with jira, then we might have a look at youtrack: * http://www.jetbrains.com/youtrack/ * http://youtrack.jetbrains.com/dashboard (300'000+ issues) * http://confluence.jetbrains.net/display/YTD3/Import+from+Mantis * http://www.jetbrains.com/youtrack/documentation/linux_installation.html both, atlassian, and jetbrains offer similar licenses, i.e. free usage for opensource projects. while i like jira lot and consider it an excellent product, youtrack was late enough to get a slim and simple user interface paired with the same basic feature set than jira. rupert.
_______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
