[Reportbug-maint] merging common stuff in python-debianbts?

Sandro Tosi matrixhasu at gmail.com
Thu Jun 12 22:07:27 UTC 2008

>> I'm replying to the original email, since I'm explaining my thoughts
>> about that:
> Does the original message's author subscribe to 'reportbug-maint'? I
> don't see any other recipients. Should they be included in the
> discussion?

No no, what I meant is to take only the original message (and not the
replies) to discuss internalli (without Bastian, then) about his

> This leads to a separate question of why the 'reportbug-ng' project
> exists, and whether the separation should continue, instead of
> concentrating our work on the existing 'reportbug' project. That may
> be more appropriate for a separate thread though.

I think (not sure) to provide a better graphical interface to
reportbug. Of course, maybe I would have been better to simply write a
GUI above reportbug, instead of forking it, but that's the situation

> Should we even bother to specify the HTML webscraping, though?
> Shouldn't we use the more structured and direct SOAP interface
> primarily, instead of codifying web-scraping as a common supported
> interface?

Sure I'd like to switch to SOAP instead of html parsing.

>> Since due to my professional work, I prefer a lot of simple "tools"
>> to do the job (a-la-unix) to join together to fulfill the higher
>> requests. So, personally, I'd like to "externalize" all common
>> activities (Bastian pointed out one, BTS interrogation) in a
>> completely separated package, but letting it be reusable.
> Yes, I agree.
> Since this interface would be closer tied to the Debian BTS than to
> any particular tool, would it make sense to define it as part of the
> 'debbugs' project? Perhaps not, since debbugs is not written in
> Python; but perhaps this Python library interface could be maintained
> as part of that project to help it remain in sync with the interface.
> Are we talking about an interface to the Debian BTS only, or to any
> 'debbugs' instance? If the latter, it would make more sense for the
> package to be named so it's associated with 'debbugs'; e.g.
> 'python-debbugs'.

Oh, well, I don't have a preference here: I'd simply like to have a
module to provide debian BTS query functionality, and reportbug to use
it; apart from that, any other functionality is welcome but, from
reportbug point-of-view, Debian bts is the main target.

>> I know, it would be a lot of work, but this way we can leverage
>> existing (i.e. tested) code while contributing with other to be used
>> in other programs.
> I'm interested to see this happen. It is timely too, since we already
> have interest within the 'reportbug' project of making the code more
> modular; the interaction with the BTS seems a prime candidate to focus
> on.

Mh, sadly the time is not so "right": ideally, the general sid freeze
will start at mid/end july, so I'd like to prepare a "legacy" (i.e.
the current code) version with as many fixes as possible for lenny,
and then from lenny+1 start to work more deeply on the shiny new
version of reportbug.

Of course, that view must be shared and agreed by all of us.


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

More information about the Reportbug-maint mailing list