I’ve been a user of Gnus for years also (at home, with much satisfaction, as it runs fine inside a GNU Screen), so I could switch to it with moderate damage. Also, as I’m using org-mode, it would be quite complementary of course, staying more in Emacs

One nice (and even priceless) feature of Evolution is the vfolders, that allow me to manage the tons of emails in different contexts, wherever that may be located. AFAIK, Gnus doesn’t offer any comparable feature. But it seems that the most interesting way to have it is to integrate Gnus with NotMuch. Fortunately, my colleague Roland has written a nice howto explaining (among other details of his mail system setup) how to integrate these together.

Now, if I’m able to setup a similar NotMuch + Gnus setup for newly received mail, I’m left with migrating all my piles of old mail, currently stored in Evolution.

It seems that one possible way to do so is through copying Evolution mail folders into a newly setup local IMAP server’s Maildir storage. The copy is supposed to preserve some flags like the read/unread status of the “important” flag.

From the first tests I’ve made, it’s possible to install a local Dovecot IMAPd server, configure it so that the mail is stored in the user’s ~/Maildir/ maildir directory, which can then be recognized by Evolution as a target for copying mail. It seems that nomuch can then be configured so that it doesn’t flag all new mails as unread, and understangs the imap server flags accordingly (unread, important, and such). Needless to say, I’m glad all these useful programs are packaged in Debian

I need to make further tests and also test Gnus + Notmuch integration, but having a possible solution to migrate my existing mail looks like a relief.

I’d be curious to read your alternative ideas for such a migration.

Stay tuned for next iterations.

If you happen to meet me, I’d be glad to have my public key signed again by you.
Here’s a copy of the new public key, and one, signed with the old.

I’ve also added a transition document here. If it suits your signing policy, you may as well sign the new key without meeting me again, if you had signed the old one already.

As usual, you may download it from keyservers with something like (for instance on keys.gnupg.net):
gpg --keyserver your-preferred-key-server --recv-key 7C5BB6A5

Attention: en raison des contraintes de sécurité pour l’accès au site, une inscription préalable est demandée (envoi des noms et prénoms à minet@it-sudparis.eu).

Update : Transparents (PDF en anglais – 1.4 Mo)

Update:

Debian: 17 ans de logiciel libre, “do-ocracy” et démocratie from Olivier Berger on Vimeo.

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.

Weaving a Semantic Web Across OSS Repositories: Unleashing a New Potential for Academia and Practice
(DOI: 10.4018/jossp.2010040103)
Authors: Olivier Berger (Institut Telecom, France); Valentin Vlasceanu (Institut Telecom, France); Christian Bac (Institut Telecom, France); Quang Vu Dang (Institut Telecom, France); Stéphane Lauriere (Mandriva, France)
in International Journal of Open Source Software & Processes (IJOSSP) Volume: 2, Issue: 2 (2010), Pages: 29-40 pp.

Here’s the abstract:

Several public repositories and archives of “facts” about libre software projects, maintained either by open source communities or by research communities, have been flourishing over the Web in recent years. These have enabled new analysis and support for new quality assurance tasks.
This paper presents some complementary existing tools, projects and models proposed both by OSS actors or research initiatives that are likely to lead to useful future developments in terms of study of the FLOSS phenomenon, and also to the very practitioners in the FLOSS development projects.
A goal of the research conducted within the HELIOS project is to address bugs traceability issues. In this regard, the authors investigate the potential of using Semantic Web technologies in navigating between many different bugtracker systems scattered all over the open source ecosystem.
By using Semantic Web techniques, it is possible to interconnect the databases containing data about open-source software projects development, which enables OSS partakers to identify resources, annotate them, and further interlink those using dedicated properties and collectively designing a distributed semantic graph.

Keywords : RDF, forge, archive, bug, semantic, semantic Web, ontology, database, repository of repositories,
interoperability, bugtracker, OSLC-CM, Debian.

The journal is published as closed content on paid access, but you may ask us, should you need to read a draft version.

This is an extended version of an earlier position paper presented at WOPDASD 2009.

This work was conducted in the frame of the “System@tic Paris-Region” cluster (http://www.systematic-paris-region.org/), with funding of the Paris Region council.

Voici la liste des interventions filmées :

• Migration à Git du projet GNOME, par Frédéric Peters (GNOME)
• Méthodes de vote : comment consulter les développeurs d’un projet sans fausser le résultat avant de poser la question, par Lucas Nussbaum (Debian)
• Développement Open Source : un retour des tranchées, le projet Jajuk, par Bertrand Florat (Jajuk)
• Comment les outils et l’esprit Open Source permettent de faire de meilleurs projets, par Erlé Le Gac, Bertrand Florat (Capgemini)

Le son n’est pas toujours top, mais c’est fait avec les moyens du bord, bénévolement

Vous trouverez les pointeurs vers les vidéos et les slides chez Free Electrons (en bas de liste).

Et n’oubliez pas : l’édition 2010 remet ça, avec un appel à contributions toujours ouvert.

Join us and discuss (in english) forge matters on discussions@planetforge.org, to try and improve communication, sharing, reuse and interoperability among various hosting platforms, and collaborative development tools.

You may prefer joining the PlanetForge RSS aggregator if you blog about forges (feel free to add it to your preferred RSS reader).

There are various use cases for this, like moving a project from one forge to another, but also as backup/restore feature for forge admins. More about the rationale here.

We’d like this format to be a standard some day, so it should have good properties so that it’s generic enough and at the same time easy to adopt. Thus it would be relatively easy to contribute new exporters or importers to an framework (for which we’ll implement basic core tools), while having a long-lasting format that can still be used in the future.

A lot of work ahead of us, and this is just a short notice in case you’re interested and you’d like to know more

Stay tuned, and if interested, join discussions@planetforge.org to discuss this topic.

P.S.: yes, it’s a rebirth of CoopX, somehow (see the coopx tag in my blog for more details)