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

[Sandro Tosi]

>> 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
email.

> 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
now.

> 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.

Cheers,
Sandro

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