[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Reusing python-btsutils for bts-link

Hello Olivier and all others,
this mail is main about bts-link, following up from #508812

On Mon, Dec 15, 2008 at 06:32:18PM +0100, Olivier Berger wrote:
> Hi.
> The package python-btsutils has been recently brought to my attention
> (Thanks zack). It implements a general python API for the DBTS.
> I think that the Debian bts querying part of bts-link
> (bts/interfaces.py) could be replaced somehow by using an (improved)
> btsutils which could use a mirror of the BTS database.
> I've started some bits to reuse current bts-link's code to extend
> btsutils, at :
> http://picoforge.int-evry.fr/websvn/listing.php?repname=helios_wp3&path=/trunk/python/ (by also changing some bits in bts-link... see : http://www-public.it-sudparis.eu/~berger_o/git/bts-link.git/)
> I've also filed a wishlist on python-btsutils for that : #508812
> The idea is to try and merge in a distinct common library as much of the
> python client interfaces of the BTS as possible. It would eventually
> support many interfaces of the BTS : SOAP, WEB, ldap, spool files,...
> Several tools could then use the same lib : bts-link, bug-triage, etc.

First of all, thanks for your interest in bts-link. Some time back
Pierre looked for an adopter [1] (and follow up on -devel[2]) for
bts-link (and I have volunteered [3] to integrate it into the QA
architecture, but I admit I didn't any progress on this :( and I
noticed you even partecipate to that thread [4] I didn't remember!).

I still think maintain the service on QA arch is the best solution,
and (I think) QA team maintain its stuff in its own svn repo only (but
I'm not sure at all about it), and I'd be happy to maintain that
service (eventually enhancing and fixing if needed, and help if
welcome as usual)

So, if we all agree QA is the way to go, I still volunteer to
integrate it (and I'll try to follow it up in the next weeks) maybe we
can merge the code in QA svn repo (but then I don't know the commit
access policy) or keep the code in git [5] and push it on QA arch
(better to just give commit access to not the whole QA code, if

Just let me know, and I'll start bothering QA gurus about policies and
procedures :)

[1] http://lists.debian.org/debian-devel-announce/2008/10/msg00006.html
[2] http://lists.debian.org/debian-devel/2008/10/msg00849.html
[3] http://lists.debian.org/debian-devel/2008/11/msg00275.html
[4] http://lists.debian.org/debian-devel/2008/11/msg00274.html
[5] http://bts-link.alioth.debian.org/

Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Reply to: