[Soc-coordination] Mylyn interface for debbugs, as a GSOC ?

Olivier Berger olivier.berger at it-sudparis.eu
Fri Mar 13 16:28:26 UTC 2009

Le jeudi 12 mars 2009 à 22:42 +0100, Obey Arthur Liu a écrit :
> Olivier Berger a écrit :
> > Le mercredi 11 mars 2009 à 22:40 -0700, Don Armstrong a écrit :
> >> On Wed, 11 Mar 2009, Olivier Berger wrote:
> >> As far as the technical feasibility goes, it's certainly possible.
> >>  
> > 
> > Well... at least for querying in read mode (SOAP, etc.) ;)... I'm not
> > exactly sure if Mylyn is able to work easily with asynchronous
> > interfaces such as bug modification in debbugs in write mode : but that
> > could be an interesting challenge.
> What interests me here is the intersection of this work with the
> DebbugsWebUI proposal[1]. If both projects pass, there could be an
> interesting collaboration between those two projects to provide a clean
> read/write API for Debbugs, possibly more SOAP-like than the current
> mail-only interface. Or stick with the mail transport, that's up to debate.
> Until now, GSoC projects in Debian have usually been very independent
> and unrelated. Having some students work together is a possibility that
> I'd like to explore.

[I'm not subscribed to soc-coordination, but have tried and read the
pipermail archive. Here are some random thoughts.]

I think that the need for a more or less synchronous access to the BTS,
be it in the form of a WEB UI, or a RW SOAP interface is something that
would certainly be a plus for debbugs.

And of course Mylyn or any other client could benefit of such a RW SOAP
interface for sure. 
I guess most people would expect a SOAP interface or a WEB UI to have an
immediate effect on the bugs, in a "synchronous" way, much like with
other bugtrackers... but I'm not sure debbugs could handle that in a
satisfying way, together with the other asynchronous mail interface
(perfomance wise, transactions + lock + concurrent changes, etc.) I
guess this should have been studied already in the past by other
people... Don ?

In any case, the 2 interfaces could be implemented on debbugs side by 2
different views of the same model and controller (to speak in MVC
terminology), which means that there would just be some intermediate API
between the SOAP "frontend" and the rest of debbugs that would be used
by the Web UI widgets also. Ideally, there should be only one entry
point in debbugs in terms of "write" commands, to make sure all the
checks are done in one place only... so of course the 2 ideas are

Now, as far as Mylyn is concerned, I must say it's not obvious how many
Debianers would be interested... and considering the lagging Eclipse
packaging, I'm a bit doubtfull...  Still, for collaborative maintenance,
Mylyn seems to promise quite interesting goals (initially targetted at
agile development and such), like sharing an environment between two
devs for a collaborative solving of a particular problem : imagine the
source of a package already loaded, the annotations on it, its bugs and
all its docs available in an Eclipse session that would be "ready to be
opened", like a kind of "maintenance SDK"... 
It makes sense, I think, if some are interested in trying to have Debian
somehow connected to the use of common tools of the IT industry like
Eclipse, Java, etc.
I see Eclipse become (like it or not) such a defacto standard for the
very many students that learn development inside it at Universities (I
know, there must still be old professors that teach them command line,
emacs, or OCaml instead of Java ;).

Anyway, I'm not so much involved in Debian that I could teach lessons on
what Debian should or not do, and this Mylyn plugin is just a proposal
for which I'd be interested in seeing what we can get as an outcome, and
which is certainly not really top priority for Debian (nor for debbugs).

Best regards,
Olivier BERGER <olivier.berger at it-sudparis.eu>
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)

More information about the Soc-coordination mailing list