[sd] OSLC-CM support in SD ?

[Olivier Berger]

Hi.

What is OSLC-CM, and why I think it could be interesting to support it
in SD (as well as in other monolithic bugtracking systems)

Context : we have been researching bugtracker interoperability for quite
a few years now, trying to think about potential use cases as large
scale bug tracking in the open source ecosystem ("same" bugs reported in
many distros' trackers as well as in upstream projects, etc.) [0]

One of the biggest blockers for implementing tools in such use cases is
the lack of standardization of the trackers APIs.

Even though the data/metadata are quite similar in trackers, there's no
such standard that has appeared (I guess SD developpers may have
interesting ideas on that matter)...

So many implementors have worked on implementing different connectors :
 - in Mylyn (32+ custom connectors to different trackers)
 - in launchpad (quite a few connectors to different distros trackers)
 - in bts-link (15 connectors to other tracker systems) [1]
 - in SD (6-8+ connectors, AFAICT)
 - ...
Not all of them are completely R+W : the most advanced being probably
Mylyn and SD (SD probably the only one to reconstruct history as a
bonus).

Then the situation has changed (at least theorically) since the proposal
set by the OSLC consortium with the OSLC-CM specs [2]. To make it short,
OSLC-CM promotes REST, RDF, JSON, AJAX, and seems to me quite a valid
standard oportunity (yeah, I contributed to the specs so I'm biased).

Now, bear with me and imagine :

      * a universal standard for tracker APIs (OSLC-CM), supported by
        more backend monolithic trackers (at the moment, for opensource
        trackers we have been developping the first server modules for
        Mantis and FusionForge [3])

      * and a distributed/P2P "middleware" (SD/Prophet) that allows
        both :

              * client apps (GUIs, etc.) to plug to it as OSLC-CM
                clients
                
              * to sync local clones with the OSLC-CM compatible remote
                trackers (including Mantis and FusionForge : 2 more for
                SD ;)

I think such an architecture would allow great apps to be developped,
and really offer large scale bug tracking capabilities.

So, all that needs to be done for this, would be :

      * developping an OSLC-CM client "backend" for SD, so that SD can
        clone bugs from an OSLC-CM compatible tracker [4]

      * developping an OSLC-CM server API for SD, so that an OSLC-CM
        client can access a local SD database (I'm not sure, but if SD
        already implements a REST API, that wouldn't be so hard, I
        guess)


We think it could be interesting to work on these ideas in the next
months, so I'd be curious to hear your questions, comments, criticisms
on these ideas.

Thanks in advance.

Best regards, 

[0] for instance my many posts on those subjects : http://tinyurl.com/2vbwdot 
[1] http://bts-link.alioth.debian.org/
[2] http://open-services.net/bin/view/Main/CmHome
[3] https://picoforge.int-evry.fr/cgi-bin/twiki/view/Oslc/Web/
[4] https://rt.cpan.org/Public/Bug/Display.html?id=60084

-- 
Olivier BERGER <olivier.berger at it-sudparis.eu>
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)