>> 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 _______________________________________________ Reportbug-maint mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/reportbug-maint
