Trying to answer some of the problems pointed out to my proposal... On Mon, Mar 17, 2008 at 2:49 AM, Russ Allbery <[EMAIL PROTECTED]> wrote:
> I think that if the goal is to support automated tools, pointing to > straight web pages isn't particularly useful without some additional > information. At the least, I'd think we'd want to specify the type of bug > system that upstream is using so that any automated tools would know what > screen scraping or (hopefully) SOAP/REST interfaces they can use. I thought about this too. But I guess that trying to model all the many things that one can find is not realistically doable. An alternative would be to use a watchfile-like system in which you provide regexes to perform the necessary text-mangling, but it has the disadvantage of being much more complex to give basic support to (I have already worked on parsing watchfiles without using uscan...), and that you need to extract a file from the source package to read the information. On the other hand, having the base pointer to the BTS, you can build up tools that can parse some systems, and if you don't know about it, you still have an URL. On Mon, Mar 17, 2008 at 2:59 AM, Paul Wise <[EMAIL PROTECTED]> wrote: > That sort of information (like watch files and homepages) changes > independently of the source package, so it would be better if it were > not added to debian/control. Well, the watch file and the homepage are actually part of the source package already. Also, I don't think that you'll find many upstreams that change BTSs more often than releasing new versions. On Mon, Mar 17, 2008 at 4:59 AM, Ralf Treinen <[EMAIL PROTECTED]> wrote: > > It could be used to automatically forward bugs, [...] > > I do not think that automatically forwarding bugs would be a good idea. Sorry if I didn't choose the exact word, I meant something on the lines of doing "bts submit-upstream-and-forward nnnnnn", without you needing to go manually through all the hops that we have to go through today. -- Martín Ferrari
