Note that the slides are at : http://rzlab.ucr.edu/debian/debbugs_presentation_debconf10.pdf, and here, I’ll only mention most noteworthy elements I’ve noticed.

There’s a linear growth of number of bugs reported for several years, from the statistics made by Don.

In average, there’s same number of bugs filed / archived per day : Debian’s not losing ground against bugs

A new “affect” command has been added, for bugs present in a package affecting another package.

The “summary” command which can be used to quickly spot the summary of lengthy discussions deserves more love. Included “summary -1″ to send a new summary by email.

The new local-debbugs package : can mirror “your” bugs locally and allow to search, show, etc. even offline.

Lots of ideas for new features still in development (but lacking manpower).

Interesting idea about “action required sorting” which exhibits different interests for triager, maintainer, user, to maximize productivity. I guess this should be implemented in clients of the BTS also.

Interesting ideas about distributed bug tracking : sharing status with other bugtrackers (see other report), sideways syncing with other distributions, and making it available to upstream also. Note this was discussed in a subsequent BoF, which I’ve already blogged about.

Some elements taken from the Q&A :

• To my question about addition of RDfa, not currently on the TODO list… I guess I’ll have to do it myself ? … Need to provide more convincing hints on the usefulness.
• only 3 status in the BTS : Fixed / Found / Absent
• some other projects are using debbugs

Overall, a very interesting presentation. Well worth watching the video recording.

See also my report on the presentation by Christine Spang on Distributing bugtracking for Debian with SD which also discussed some debbugs things.

This is just some elements of report (some taken from the gobby edits, and written down by me after watching the video (unfortunately missing 2 mins of sound in the beginning of the video stream/recording)). This is not a full report of all the discussions, as some discussed elements weren’t of interest IMHO.

You’ll find here many ideas of mine, links and pointers (resulting of our work in the context of the Helios project on similar topics), so this is in no way a report of what was said exactly during the BOF.

Aspects of interest:

• for Debian bugs
  • Sharing state between upstream, downstream and sidestream
    • Forwarding upstream
  • Sharing comments between the same bugs
  • merging / conflict resolution (technically challenging, as well as in order to match people’s habits/process)
• Same problem in general
  • distributed bug tracking
    • working offline (modify locally, push, etc.)
  • but also distributed version/commit tracking : tracking bug presence or fix along the branches of commits in distributed VCSes
• Interop with other bugtrackers:
  • method to pass data back and forth between different bugtrackers
  • standard method / format / API : lack of standard widely used
  • visibility of issues known upstream (or elsewhere) to Debian users while using “reportbug”
  • scraping other trackers

Note that these topics may in principle be discussed on the Distributed bug trackers mailing list: http://kitenet.net/cgi-bin/mailman/listinfo/dist-bugs

Tools / implementation ideas :

• First, there’s a wiki resource about lots of software tools : http://dist-bugs.kitenet.net/software/
• SD (presented later by Christine Spang – see my other blog post about her great presentation)
• LaunchPad’s tracker already knows about lots of other bugs in other distros including Debian bugs (through “bug tasks”)
• bts-link watches links between bugs and status changes (mainly through scraping)
• Generic scraping tools could be used :
  • Scraperwiki (http://scraperwiki.com/)
  • or WebReformatter (http://code.google.com/p/webreformatter/
• Virtuoso spongers to perform on the fly conversion of bugs XML feeds to RDF to inject them in a RDF store (ex: search “bugzilla” inside http://www.openlinksw.com/dataspace/dav/wiki/Main/RDFMappersUseCases)

Storage of repositories / databases of remote bugs :

• Mail … lots of suggestions, but to be discarded IMHO
• in users’ Virtuoso RDF stores, eventually in an integrated way with the Semantic Desktop (KDE 4.4 / Tracker / Zeitgeist) which may be an option (integrating bugs in other desktop tools aware of the semantic desktop).
• through desktopcouch (as used by the bughugger client for LP tracker – see the bughugger presentation at RMLL/LSM 2010)

About such storage, and the RDF store option, here’s a prototype of ours that exposes UDD’s bug facts through a SPARQL interface, allowing to publish bug facts as RDF (setup in the frame of the Helios project). It includes both Debian and Ubuntu bugs, and allows interlinking them in a “standard” way (with Semantically described links in RDF). See http://testforge.int-evry.fr/d2r-server/resource/spackage/evolution for an example.

The problem is not how to distribute (distributed database systems exist), but the semantics of bug properties, and the different implementations of interfaces of different tools : which standard to implement, or how many converters are necessary if no standard ? We believe that navigation/referencing/tracking of external bugs would be much easier if bugs were LinkedData citizens, i.e. they would be exposed with (standard) formats like Semantic Web ontologies served with Semantic Web standards (like RDF).

The worst case is currently to have to perform web scraping on bugtracker interfaces. How to avoiding scraping ? A solution could be to publish RDFa / microformats using common standard semantics, directly from the bugtracker pages at bugs URLs (see my wishlist for debbugs on that subject : 590931: Would be great to integrate RDFa metadata into debbugs pages).

Now some pointers to historical details on the same subject and Debian (old posts by Lars Wirzenius) :

• “Distributed bug tracking”
• “Bug exchange format”

Overall, the discussion was quite interesting, but didn’t reach any sensitive progress regarding the state of the art. Much needs to be worked on, mainly on standardizing APIs, semantic descriptions of bugs, and implementation in tools like SD for instance. Stay tuned for more progress.

Hopefully, the slides are gonna be published soon, but in the meantime, you have them in the video recording (see link above) – EDIT: she has published here slides : see her blog post.

For those who don’t know SD, they may refer to a talk given by its author, Jesse Vincent, at the recent RMLL/LSM 2010 : Peer to peer issue tracking with SD and Prophet (video recording coming soon : EDIT: a premiere recording is available here).

She draws 2 main use cases in her speech, which is exactly the kind of features we’ve been thinking about for fetchbugs4.me :

• as a Debian maintainer : SD may be used to clone into your local SD repository all tickets related to your activity on your packages in debbugs.
• or as both a Debian maintainer and upstream developper, you’d combine bugs from Debian’s debbugs and upstream’s bugtracker in one same bug database.

What would be even better is to be able to link all of these bugs to each-other… but I’m not sure this is yet possible.

Christine started implementing debbugs (Debian’s bugtracker) support in SD. For reference, there’s a wishlist about it in 590156 : sd: Provide sync-ing with debbugs. The implementation is still in alpha state, in read-only mode only.

Christine has implemented a new method get_{machinereadablebuglog}() for debbugs’ SOAP interface. It seems to send some Perl Data::Dumper output, which is probably fine for SD as SD is written in Perl, like debbugs… but it may be better if it was some more generally accepted format, like JSON maybe.

Among the topics discussed, was the absence of any standard API to connect to bugtrackers, meaning that SD needs to include many different client code modules for each of the trackers different APIs over different kinds of protocols. I’ve raised (through my IRC comments, watching the presentation through the stream), that there’s a proposal for such a standard that exists : OSLC-CM. Still, it’s not widely implemented, in particular in Open Source tools (see another post of mine on the subject). I think it would be great if SD could be a client of OSLC-CM compatible trackers, hence I’ve filed a wishlist.

Also, I suggested that maybe it would be interesting to be able to browse the mail threads of comments on Debian bugs, much like with “bts –mbox show 12345″ command (which opens mutt on the bugs’ thread, for me), when in offline mode, with SD. Maybe the bts command could just use SD as a backend for all its operations.

Another very interesting feature may be to allow “transfering” a Debian bug to an upstream bugtracker, through SD. Dunno if that will be possible.

Finally the code may be found : in github.

I’m looking forward to testing it.

Here’s a pointer to the first webcast on fetchbugs4.me’s blog, with more details.

The goal is to be able to track remote bugs with bts-link even for your own list of (private) bugs that are not in debbugs (see also prevous post about this idea we work on in the Helios project).

Now, I have some bugs in Mantis, and I add a snippet like the following into one of its notes :
*** bts-link-mantis variables ***
Forwarded-To: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528192
*** end bts-link-mantis ***


And starting from that point, bts-link is able to monitor the (remote) Debian bug it refers to, and notify people subscribed to the local Mantis bug.

When running and if the Debian bug status changes, it will add (via SOAP) another note with, for instance :

This is a note generated by bts-link :
remote status report for 0000029
* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528192
* remote status changed: (?) -> pending
*** bts-link-mantis variables ***
Forwarded-To: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528192
User-Tags: status-pending
*** end bts-link-mantis ***


The same principle would work with almost any bugtracker even if they don’t support forwarded-to tags or any similar remote bug tracking mechanism natively.

The code is here (git), for the curious ones.

EDIT 2009/07/03 : I announced this to the Mantis-dev list hoping there will be some feedback.

We’ll probably try and work, until July, on connecting to Mantis as the “distribution/downstream” bugtracker instead of debbugs, and see what architectural changes would be required to test that for the Helios platform specific needs.

I’d like to be able to have a working prototype for July, which would also demonstrate the LinkedData and Semantic Web approach to navigating the bugs of the open source ecosystem, so that we can discuss it at the Debconf. I’ve filed a proposal for a paper at DebConf for this purpose : towards more semantic web into Debian servers (UDD and likes) (see previous post on that matter also).

I suppose that our Mandriva colleagues will be able to move on on bugzilla for SWIM/Mephisto so that we can quickly have very interesting prototypes.

I miss time to describe all that in more details (and will appreciate the coming holidays week ).

Comments welcome, of course.

I’ve prepared some slides of introduction for our partners in Helios to introduce them to that tool :

These slides can also be found on the helios site (ODP source).

Also, I’ve started contributing to bts-link in the frame of our work on Helios, and I’m glad my contributions have been integrated, although learning git in the way was kind of a pain

More details about bts-link at : http://bts-link.alioth.debian.org/