Help bringing bugs.debian.org / debbugs back on track (Re: bits from the DPL -- September 2013)
On 2013-10-09 01:58, Lucas Nussbaum wrote:
Here is my monthly report for September 2013 (+ the beginning of October).
Let's also use this opportunity to call for help on two key parts of our
Call for help: debbugs developers
debbugs is the piece of software behind the Debian Bugs Tracking System
(BTS). It is also used by the GNU project. Despite often being
perceived as old-style, it features several unique features, such as the
tracking of the status of bugs in each version and branch of a package
(example: ), or the ability to perform all interactions via email,
making it very easy to work offline or in poorly-connected environments.
Debbugs is written in Perl, its source is available from , there is a
testing harness available, and lists of known bugs are available from
http://bugs.debian.org/bugs.debian.org (Debian instance of debbugs) and
http://bugs.debian.org/debbugs (debbugs itself). Direct questions to the
debian-debbugs@ mailing list.
Thanks for bringing this up, our ITS definitely needs love. I investigated the ITS team in 2010 and found it was already broken (although one member disagreed with that assessment, qualifying the team's status as "fine"). The most urgent issue must be fixing the administration of bugs.debian.org, but development should also be a priority.
However, I am not convinced that development of bugs.debian.org should go through Debbugs development. Unfortunately, I am not an ITS-s expert, and I can't recommend a particular engine. There are many free ITS engines, some of which are worst, but in general, as an engine user, I do not like Debbugs compared to most other engines. Debbugs's technology doesn't look great, but I'm entirely unaware of the internals. My skepticism on its future really comes from the current number of users and developers, and most importantly its advancement compared to alternatives. I can only agree that the ITS needs help and that Debbugs can use development, but I'm not convinced that's an optimal use of our currently nearly inexistent ITS manpower (see https://lists.debian.org/stats/debian-debbugs.png ).
Any manpower we can find should be used as efficiently as possible, and if we won't have enough to keep a custom ITS going, we should consider migrating to a "COTS" system. A one-time effort like this may be suitable for student projects. That being said, we also should not underestimate the efforts needed for a proper migration: implementing missing features in the selected system, adapting our ITS-based tools to it as well as migrating the data. As you write, Debbugs has a few things which most others don't.
As far as I know, the suitability of Debbugs hasn't been reevaluated recently... if it ever was. So I simply suggest people willing to get involved in the ITS to have perennity in mind before investing in Debbugs.
- debbugs submissions via http (C: ? ask asheesh)
I imagine this won't be news, but this is tracked in #590269. Interesting project by the way (although I miss that less since I moved to reportbug-ng).