Search Results: "Olivier Berger"

24 August 2012

Olivier Berger: Generating RDF description of Debian package sources with ADMS.SW

Edit : I ve now managed to roll out my contribution which is now in production on packages.qa.debian.org. See a later post I ve made on the subject, and beware that the generated RDF has changed a bit also. ADMS.SW proposes specifications for description of software present in software catalogues. I ve tried and apply it to the contents of the Debian Package Tracking System (PTS), using transformation of the information known by the PTS to RDF+XML. The result is not yet in production, but here s an example of what can be done, using the Turtle syntax (more readable) :
<style type="text/css"> .T1 color:#000000; font-size:14pt; font-weight:bold; .T2 color:#000000; font-size:12pt; .T3 color:#000000; font-size:8.5pt; .T4 color:#0000ff; font-size:8.5pt; .T5 color:#a020f0; font-size:8.5pt; .T6 color:#228b22; font-size:8.5pt; .T7 color:#b22222; font-size:8.5pt; .T8 color:#008b8b; font-size:8.5pt; .T9 color:#8b2252; font-size:8.5pt; .dp1 .dp2 </style> @base <http://packages.qa.debian.org/> .
@prefix rdf: <http://www.w3.org/1999/02/22 rdf syntax ns#> .
@prefix admssw: <http://purl.org/adms/sw/> .
@prefix doap: <http://usefulinc.com/ns/doap#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf schema#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix schema: <http://schema.org/> .
@prefix spdx: <http://www.spdx.org/rdf/terms#> .
@prefix : <http://www.w3.org/1999/xhtml> .
@prefix str: <http://exslt.org/strings> . #
# First the packaging project for apache2 in Debian
#
# <http://packages.qa.debian.org/apache2> resource :
<apache2>
a admssw:SoftwareProject ;
doap:name "apache2" ;
doap:description "Debian apache2 source packaging" ;
doap:homepage "http://packages.debian.org/src:apache2" ;
schema:contributor [
a foaf:OnlineAccount ;
foaf:accountName "Debian Apache Maintainers" ;
foaf:accountServiceHomepage <http://qa.debian.org/developer.php?login=debian apache@lists.debian.org>
], [
a foaf:OnlineAccount ;
foaf:accountName "Stefan Fritsch" ;
foaf:accountServiceHomepage <http://qa.debian.org/developer.php?login=sf@debian.org>
], [
a foaf:OnlineAccount ;
foaf:accountName "Steinar H. Gunderson" ;
foaf:accountServiceHomepage <http://qa.debian.org/developer.php?login=sesse@debian.org>
], [
a foaf:OnlineAccount ;
foaf:accountName "Arno T ll" ;
foaf:accountServiceHomepage <http://qa.debian.org/developer.php?login=arno@debian.org>
] ;
# pointer to the release in the different suites :
doap:release <apache2_2.2.16 6+squeeze7>, <apache2_2.2.22 11>, <apache2_2.4.2 2>. #
# Now the different debian package source releases
#
# <http://packages.qa.debian.org/apache2_2.2.16 6+squeeze7> resource
<apache2_2.2.16 6+squeeze7>
a admssw:SoftwareRelease ;
rdfs:label "apache2 2.2.16 6+squeeze7" ;
admssw:project <apache2> ;
dcterms:description "Debian apache2 source package version 2.2.16 6+squeeze7" ;
doap:revision "2.2.16 6+squeeze7" . # This one is the reference version for the PTS as in unstable, so
# contains more details than the others
<apache2_2.2.22 11>
a admssw:SoftwareRelease ;
rdfs:label "apache2 2.2.22 11" ;
admssw:project <apache2> ;
dcterms:description "Debian apache2 source package version 2.2.22 11" ;
doap:revision "2.2.22 11" ;
# this release contains two components
admssw:includedAsset <apache2/apache2_2.2.22 11_debian>, <apache2/apache2_2.2.22_orig>
;
# this release can be downloaded as one package (with dget)
admssw:package <apache2/apache2_2.2.22 11.dsc> ;
# it also has a related release somewhere else
dcterms:relation <https://launchpad.net/ubuntu/+source/apache2/2.2.22 6ubuntu2> .
<apache2_2.4.2 2>
a admssw:SoftwareRelease ;
rdfs:label "apache2 2.4.2 2" ;
dcterms:description "Debian apache2 source package version 2.4.2 2" ; admssw:project <apache2> ;
doap:revision "2.4.2 2" . # Then the .dsc file for the current unstable version
<apache2/apache2_2.2.22 11.dsc>
a admssw:SoftwarePackage ;
dcterms:description "Debian source package descriptor file for apache2 version 2.2.22 11";
schema:downloadUrl "http://cdn.debian.net/debian/pool/main/a/apache2/apache2_2.2.22 11.dsc";
schema:fileSize "2885" ;
spdx:checksum [
a spdx:Checksum ;
spdx:algorithm <apache2#checksumAlgorithm_md5sum> ;
spdx:checksumValue "d7d03719b9f6432beeecd3aa04f7b22c"
] . #
# Then the upstream project
#
<apache2/apache2_orig>
a admssw:SoftwareProject ;
doap:description "The apache2 upstream project" ;
# either its name or homepage can be matched against other ADMS.SW
# or DOAP descriptors
doap:name "apache2" ;
doap:homepage "http://httpd.apache.org/" . # And a upstream release 2.2.22
<apache2/apache2_2.2.22_orig>
a admssw:SoftwareRelease ;
rdfs:label "Upstream apache2 release 2.2.22" ;
dcterms:description "Upstream source release for apache2 version 2.2.22" ;
doap:revision "2.2.22" ;
admssw:project <apache2/apache2_orig> ;
# and a link to the upstream source tarball s description
admssw:package <apache2/apache2_2.2.22.orig.tar.gz> . # now the (potentially re archived) upstream source archive for that release
<apache2/apache2_2.2.22.orig.tar.gz>
a admssw:SoftwarePackage ;
dcterms:description "Upstream source archive for apache2 version 2.2.22 11 (potentially re archived by Debian)";
schema:downloadUrl "http://cdn.debian.net/debian/pool/main/a/apache2/apache2_2.2.22.orig.tar.gz";
# Those 2 bits should help match packagings of the same tarball if needed
schema:fileSize "7200529" ;
spdx:checksum [
a spdx:Checksum ;
spdx:algorithm <apache2#checksumAlgorithm_md5sum> ;
spdx:checksumValue "d77fa5af23df96a8af68ea8114fa6ce1"
] . #
# Now, document specific details of the second component : Debian
# packaging files archive
#
<apache2/apache2_2.2.22 11_debian>
a admssw:SoftwareRelease ;
rdfs:label "Package sources apache2_2.2.22 11" ;
dcterms:description "Debian packaging sources for apache2 version 2.2.22 11" ;
doap:revision "2.2.22 11" ;
admssw:package <apache2/apache2_2.2.22 11.debian.tar.gz> . <apache2/apache2_2.2.22 11.debian.tar.gz>
a admssw:SoftwarePackage ;
dcterms:description "Debian source package files archive for apache2 version 2.2.22 11" ;
schema:downloadUrl "http://cdn.debian.net/debian/pool/main/a/apache2/apache2_2.2.22 11.debian.tar.gz";
schema:fileSize "195980" ;
spdx:checksum [
a spdx:Checksum ;
spdx:algorithm <apache2#checksumAlgorithm_md5sum> ;
spdx:checksumValue "d3d4146ccad51129636b7dbff284a110"
] . #
# Now, we also weave links with the Ubuntu counterparts
#
<https://launchpad.net/ubuntu/+source/apache2>
a admssw:SoftwareProject ;
doap:description "\"apache2\" source package in Ubuntu" ;
# this one promises some trolls and flames
admssw:forkOf <apache2> ;
doap:homepage "https://launchpad.net/ubuntu/+source/apache2" ;
doap:release <https://launchpad.net/ubuntu/+source/apache2/2.2.22 6ubuntu2> . # and its release known by the PTS
<https://launchpad.net/ubuntu/+source/apache2/2.2.22 6ubuntu2>
a admssw:SoftwareRelease ;
rdfs:label "apache2 2.2.22 6ubuntu2" ;
dcterms:description "\"apache2\" 2.2.22 6ubuntu2 source package in Ubuntu" ;
doap:revision "2.2.22 6ubuntu2" ;
admssw:project <https://launchpad.net/ubuntu/+source/apache2> .

31 January 2012

Olivier Berger: ADMS.F/OSS : standardizing meta-data for software description in forges or software catalogues

Maybe this could be of interest to a few of my readers who may have missed the announcement, in particular for ones related to forges which will be deployed for private administrations in Europe. The recently stared ADMS.F/OSS project is described as :
ADMS.F/OSS is an XML and RDF vocabulary to describe software, in
particular free and open-source software (F/OSS), making it possible to
more easily search and discover software. The ADMS.F/OSS specification is still under development.
It is developped in the frame of an EC (European Community) programme for interoperability between public administrations (more on the page above). I ll try and participate to the working group, bringing in some feedback from the efforts on similar issues conducted during the (now over) COCLICO project. Hope this helps.

29 August 2011

Sylvestre Ledru: Debian identi.ca / Twitter feed: removed packages

After a request from Olivier Berger, I developed the Removed packages feed for Debian. This feed lists packages removed from the Debian Archive. Debian removed packages on Identi.ca
Debian removed packages on Twitter
For more information about removed packages

19 July 2011

Olivier Berger: Migrating mail from Evolution local storage to Evolution + local Imap (dovecot with Maildir) 2/X

See previous post for the rationale. I ve then started migrating my mail using evolution. First I ve installed dovecot and set it up so as to store my mail inside my $HOME/Maildir/ dir. Evolution will run dovecot on demand through a pipe, instead of through network access like with regular remote IMAP servers. So dovecot won t be started as a daemon. I ve been inspired by Roland s setup for this (even though I not using offlineimap). Inside Evolution, I ve configured a second mail profile, for this local IMAP server, using the custom command to connect to server :
"MAIL=maildir:$HOME/Maildir /usr/lib/dovecot/imap" I ve migrated my existing mail folders using copy to function on all top-level mail folders from the local evolution storage, to copy them to the IMAP folders. Note that some folders that include a dot ( . ) need to be renamed, as the dot is a path separator for IMAP. I ve adapted Evolution s vfolders definitions so as to take into account the active remote folders instead of the local ones, and that s it, the mail is migrated. I m using fetchmail + procmail to fetch mail from remote servers and to deliver it to the Maildirs, using dovecot s deliver program, with something like : DELIVER="/usr/lib/dovecot/deliver" :0: w
$DELIVER
I ve migrated the filters of evolution to server-side Sieve rules so that dovecot s deliver sorts incoming mail in the right Maildirs. The dovecot config needs to be adapted to activate the sieve plugin (dovecot-sieve Debian package), in /etc/dovecot/conf.d/15-lda.conf : protocol lda
# Space separated list of plugins to load (default is global mail_plugins).
mail_plugins = $mail_plugins sieve
log_path = /tmp/dovecot-deliver-errors.log
info_log_path = /tmp/dovecot-deliver.log

The original Evolution filters rules were stored in $HOME/.config/evolution/mail/filters.xml, so I wrote a quick python DOM parsing tool to extract the (long) list of definitions and generate Sieve rules for the $HOME/.dovecot.sieve config file (in which folder hierarchy uses a . path separator instead of a / ). The sieve-test program can be used to check is sieve rules function as you want. Now this is all setup, I only need to configure notmuch to index all the Maildirs. But this is left to another post.

Olivier Berger: Migrating mail from Evolution local storage to Evolution + local Imap (dovecot with Maildir) 1/X

I ve been fed up with Evolution being so buggy and slow, which was making managing my mail ever more painful as time passes. Still, one of the advantages of Evolution over other MUAs is the vfolders feature, which I ve been using intensively for years. Would there be some alternate way of managing my mail ? I ve been reading about notmuch s progress in becoming a very powerful mail management / retrieval tool (it could very well replace the vfolder feature of Evolution), but unfortunately, it is not (yet) integrated with Evolution. Others have documented their mail setup, and it seems that I could achieve a middle ground solution by migrating all my mail folders, currently stored inside Evolution s local storage, into Maildir folders managed by a local dovecot IMAP server. Evolution would still be my MUA, but it would store my mail inside Maildirs through dovecot. I ve been told that Evolution may be less buggy with IMAP than with local folders, which could solve my main annoyances. Also, it would make it possible to index mail with notmuch, as it supports the Maildir storage format. I ve then decided to take the opportunity of a holiday period to start the migration attempt. I ll document it in another post.

27 June 2011

Olivier Berger: Migrating from Evolution to Gnus + NotMuch (part 1)

I ve gotten fed up with Evolution s bugs and slowness. Even though I experience less problems than some weeks ago since I ve applied a patch related to locks in e-d-s, Evolution has now become really too slow and given that my mail flow is not really diminishing, I ve come to the point when I think about migrating. 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.

16 June 2011

Olivier Berger: Debian business card made with GLabels

Unfortunately, GLabels is currently unmaintained. Still, it's a very convenient tool, IMHO to print DIY business cards. Here's my glabels business card file, for those interested to borrow and reuse it.

23 May 2011

Olivier Berger: I'm now a Debian Developer

As of today, I'm now obergix@debian.org. I've been a Debian contributor (more recently as Debian Maintainer) for quite a while, and after a few months of procedures, I've now been accepted as a registered Debian Developer, i.e. a Debian project's member. Thanks for all the good folks that have helped me doing so, by advocating, reviewing my application, or just inspiring me ;) Now, that's not an achievement, just a start, and I hope I'll be able to help improve Debian a bit.

29 March 2011

Olivier Berger: New stronger personal GnuPG key

I have generated a new GPG key (4096R/7C5BB6A5) associated to my personal identity, for the needs of my application as Debian Developer. Therefore, the old key (1024D/B4C5F37F) will soon be retired. 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

12 August 2010

Olivier Berger: Report on Debbugs New developments in the ongoing struggle against bugs by Don Armstrong at Debconf

Here are some notes I took about the lecture Debbugs New developments in the ongoing struggle against bugs by Don Armstrong at Debconf 10 (that I watched from the stream). 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 : 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.

Olivier Berger: My report after the BOF on distributed bugtrackers at DebConf

Here are my notes about the very insteresting BOF on distributed bugtrackers held at DebConf 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: 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 : Storage of repositories / databases of remote bugs : 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) : 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.

Olivier Berger: Great talk Distributed bug tracking for Debian with SD at DebConf

This is a quick report and notes about the great presentation made at DebConf on Distributed bug tracking for Debian with SD by Christine Spang (http://penta.debconf.org/dc10_schedule/events/591.en.html) Hopefully, the slides are gonna be published soon, but in the meantime, you have them in the video recording (see link above). 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 : 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 getmachinereadablebuglog() 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.

29 July 2010

Olivier Berger: Weaving a Semantic Web Across OSS Repositories: Unleashing a New Potential for Academia and Practice published

A new paper of ours was just published. If you re curious about all that Semantic Web and Linked Data hype and how it would impact forges and other software development tools, and the link with Open Source development platforms, then, read this :
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.

10 May 2010

Stefano Zacchiroli: UDD - consolidating bazaar metadata for QA and data mining

Eclectic paper on the Ultimate Debian Database A few months ago, I've co-authored with Lucas a paper on UDD, which has just been presented at this year IEEE's Mining Software Repository conference, continuing my recent tradition of eclectic papers. The paper is titled The Ultimate Debian Database: Consolidating Bazaar Metadata for Quality Assurance and Data Mining and is available for download from my publications page. For Debian people already familiar with UDD there is probably not much to learn from it, as the main target of the paper is the community of scientists doing data mining on software repositories. For them, UDD offers a valuable entry point to Debian "facts", as data sources reflected in the database are easily joinable together and to some extent already validated by other UDD users (e.g. QA people). Nevertheless the first two sections of the paper are probably of more broad interest. There we have given our point of view on the so called Debian Data Hell: why it exists, how it's related to the nature of Debian and similar distros, etc. I've already noted in the past how that is also related to the culture of freedom that in Debian we value not only in our software, but also in our infrastructure and procedures. We should just get rid of a bit of inertia, and total world domination will then be just around the corner :-) I'm happy to conclude quoting the acknowledgments section of the paper: Acknowledgments
The authors would like to thank all UDD contributors, and in particular: Christian von Essen and Marc Brockschmidt (student and co-mentor in the Google Summer of Code which witnessed the first UDD implementation), Olivier Berger for his support and FLOSSmole contacts, Andreas Tille who contributed several gatherers, the Debian community at large, the "German cabal" and Debian System Administrators for their UDD hosting and support.

19 February 2010

Olivier Berger: Vid os de certaines confs du th me D veloppement des RMLL 2009

Free Electrons vient de mettre en ligne des vid os des conf rences qu ils ont film es aux RMLL 2009.
Une partie des vid os porte sur le th me D veloppement que j ai coordonn . Voici la liste des interventions film es : 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.

8 February 2010

Olivier Berger: New inter-forges discussion list on planetforge.org

You work on developing a software forge, you re an admin for a software forge, or a project administrator. 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).

Olivier Berger: Working on standard forge exchange format

As part of COCLICO, we re working on an exchange format for forges, that should help dump, restore, export and import from different software forges. 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)

17 January 2010

Olivier Berger: Some news of our efforts around OSLC-CM and future plans

OSLC-CM V1 is a proposed standard for REST APIs of bugtrackers, and in our seek for more interoperability in the bugtracker space, we ve been very interested in it. OSLC-CM is quite young and only so far implemented in proprietary tools (although elaborated in an open way) on the server side, and as we believe in FLOSS, we ve started trying to implement basics of server side plugins for a few bugtrackers.
In addition to a demo server that s simulating the behaviour of a bugtracker, we have started implementing a Mantis plugin and FusionForge and Codendi trackers add-ons (all PHP and based on Zend framework, see this project on picoforge). All are very basic, but we hope they will be the basis for future OSLC-CM compatible servers in these tools. At the same time we ve been experimenting with the code already published in Mylyn to support OSLC-CM on the client side. Not everything is public yet in Mylyn, as the elements that have been developped for some connectors of Tasktop to the proprietary tools are being ported to the open source code of Mylyn.
We have thus been able to use the Junit tests classes of Mylyn and tweak them in a way to connect to an instance of the demo server for Mantis (including handling some Basic auth), and be able to retrieve the first bugs descriptions :-) Now that this works, we ll try and add some Java code (maybe reusing Mylyn client libs) to doc4 (being developped as part of Helios) in order to start linking doc4 and Mantis so that this can be used in the Helios platform. This may involve mixing code of XWiki and Mylyn hmmm well, we ll see. Next steps may be also to try and implement a connector in Python that might be used in tools like bts-link. Then whichever Python or Java client libraries we have, will allow us to use them inside FetchBugs4.me to connect and harvest bugs of OSLC-CM compliant bugtrackers eventually. Lots of interesting developments ahead. Stay tuned.

7 December 2009

Olivier Berger: RIP twiki in Debian

The twiki package has been removed from Debian. The package was not really maintained, and twiki s maintenance still required some attention, as there were quite a lot security issues. So the removal is logical. I had tried and help maintain it in good shape, but couldn t do much recently, as we ve moved a little bit away from its inegration in PicoForge, having other matters to care for in Helios and Coclico these days. Maybe foswiki (the more open fork of twiki) will enter Debian some day. The ITP is there, and there are unofficial packages to be tested, for those that would need to transition from the previous installations of twiki on Debian. More details in the fowsiki ITP. Anyway, thanks for all the good work to all those who spent time working on TWiki s packages in Debian. As for me, maybe some day, I ll be interested in contributing some time to Foswiki, should we deploy it alongside FusionForge some day.

3 October 2009

Olivier Berger: First webcast of a demonstrator of our bug ontology s use

We have setup, as part of our work in Helios, a very early demonstrator of a database of RDF facts about bugs in several distributions (currently Debian and Mandriva), in order to try and validate the Ontology describing bugs that we develop. Here s a pointer to the first webcast on fetchbugs4.me s blog, with more details.

Next.

Previous.