Re: Proposing a new source control header to link to upstream BTSs
In March, I proposed adding some useful (to me) fields to the control
file, along this idea:
Upstream-Bug-Browser: http://rt.cpan.org/Public/Dist/Display.html?Name=WWW-Curl
Upstream-Bug-Submitter: http://rt.cpan.org/Public/Bug/Report.html?Queue=WWW-Curl
Which were furiously rejected by many people, in the usual and
friendly tone commonly seen in -devel.
Do that please but keep your fingers off the Packages files. The value
of your meta information is not worth the costs of its distribution to
every user's local system.
But just now I saw this in the dpkg changelog:
dpkg (1.7.0) unstable; urgency=low
{..}
* Add Origin and Bugs fields to the control file
{..}
-- Wichert Akkerman [EMAIL PROTECTED] Sun, 5 Nov 2000 17:28:39 +0100
Those were documented (or so) in deb-control(5) only last October, so
it's no wonder nobody replied telling me that the idea I had was
already implemented more than 7 years ago! Currently, there are about
two source packages in the archive using these fields.
There's no mention that I could find of those fields in the Debian
Policy nor in the Dev Ref. I guess that reading dpkg source code
should be added as a requirement to the NM templates.
--
Martín Ferrari
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposing a new source control header to link to upstream BTSs
On Thu, 22 May 2008, Martín Ferrari wrote:
Upstream-Bug-Browser:
http://rt.cpan.org/Public/Dist/Display.html?Name=WWW-Curl
Upstream-Bug-Submitter:
http://rt.cpan.org/Public/Bug/Report.html?Queue=WWW-Curl
Which were furiously rejected by many people, in the usual and
friendly tone commonly seen in -devel.
[...]
But just now I saw this in the dpkg changelog:
dpkg (1.7.0) unstable; urgency=low
{..}
* Add Origin and Bugs fields to the control file
{..}
-- Wichert Akkerman [EMAIL PROTECTED] Sun, 5 Nov 2000 17:28:39 +0100
Those were documented (or so) in deb-control(5) only last October, so
it's no wonder nobody replied telling me that the idea I had was
already implemented more than 7 years ago! Currently, there are about
two source packages in the archive using these fields.
Those fields are unrelated to your proposal. Origin: is meant to be
a distribution name (Debian/Ubuntu/Xandros) and Bugs: should point
to the bug tracker of the distribution.
The goal is that reportbug installedpackage sends the information to the
right bugtracker even if you installed an external package on your Debian
machine.
There are plans to make real use of those fields in the not-so-distant
future, so don't reuse them for unrelated purpose.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposing a new source control header to link to upstream BTSs
Ralf Treinen wrote: I do not think that automatically forwarding bugs would be a good idea. Right now it is a pain to forward a bug, say to a sourceforge bug report, because it involves several steps: 1. Log into sourceforge 2. Create bug report, copy link to Debian bug report into it. 3. Send message to Debian bug report stating that the bug report has been forwarded. 4. Send email to [EMAIL PROTECTED] marking the bug as forwarded. 5. Wait for response (seems to take ages), fix any errors that occurred, go back to step 4. Generally, I always seem to find new and exciting ways of stuffing up step 4 (e.g. linking to wrong sourceforge bug, using forward instead of forwarded, sending mail to [EMAIL PROTECTED], etc), which just prolongs the entire task and makes it more tedious. It would be good if this process could be automated, however I suspect this header is not the solution. Brian May. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposing a new source control header to link to upstream BTSs
Brian May [EMAIL PROTECTED] writes: 4. Send email to [EMAIL PROTECTED] marking the bug as forwarded. 5. Wait for response (seems to take ages), fix any errors that occurred, go back to step 4. Generally, I always seem to find new and exciting ways of stuffing up step 4 (e.g. linking to wrong sourceforge bug, using forward instead of forwarded, sending mail to [EMAIL PROTECTED], etc), which just prolongs the entire task and makes it more tedious. I could never figure out why people used the bts command from devscripts until one day it dawned on me that it prevents many of those problems by syntax-checking your commands for you and always sending mail to the right address. Then I started using it religiously. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposing a new source control header to link to upstream BTSs
Quoting Neil Williams ([EMAIL PROTECTED]): Please can this 'trend' be stopped here and now? The Packages.gz file is already enormous (especially for Emdebian purposes or other low resource units) and adding yet more fields to Couldn't there be an opportunity somewhere to have some possible hook in dpkg/apt/whatever that could drop specific fields on control files when the Packages file is written/updated on disk? This could be set by local admins...or there could be a default per-architecture...whatever. That would then achieve the goal of reducing the Packages.gz file size in low resources environments (why not even drop the long description when resources are very scarce?) without preventing innovative initiatives such as this one -- signature.asc Description: Digital signature
Re: Proposing a new source control header to link to upstream BTSs
On Tue, 18 Mar 2008, Christian Perrier wrote: without preventing innovative initiatives such as this one Sometimes innovation comes silent. I remember times when we have hidden Homepage information behind 'XCBS-URL'. So why not using XCBS-UpstreamBTS or something like that and experiment with this and see how it might evolve? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposing a new source control header to link to upstream BTSs
On Tue, Mar 18, 2008 at 04:29:41PM +1100, Brian May wrote: Ralf Treinen wrote: I do not think that automatically forwarding bugs would be a good idea. Right now it is a pain to forward a bug, say to a sourceforge bug report, because it involves several steps: [...] It would be good if this process could be automated, however I suspect this header is not the solution. Granted, but then you are speaking about giving better tool support for manually forwarding bugs, which is not the same thing as automatically forwarding bugs. Better tool support would of course be welcome. Cheers -Ralf. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposing a new source control header to link to upstream BTSs
On Tue, 18 Mar 2008, Andreas Tille wrote: XCBS-UpstreamBTS or something like that and experiment with this and see how it might evolve? I'm opposed to this as well. Homepage and Vcs-* were almost required and provide the basic pointers about a package but the control file is not a general-purpose information file. Please work on something like Mole/CRMI if you want to associate much more metadata to packages. http://wiki.debian.org/Mole http://wiki.debian.org/CRMI Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposing a new source control header to link to upstream BTSs
On Tue, 18 Mar 2008, Raphael Hertzog wrote: On Tue, 18 Mar 2008, Andreas Tille wrote: XCBS-UpstreamBTS I'm opposed to this as well. Homepage and Vcs-* were almost required and provide the basic pointers about a package but the control file is not a general-purpose information file. Well, could you please draw a border line between almost required and general-purpose? For some time we had XCBS-debtag information in the control file and learned that this is suboptimal. So why not trying an experiment? I doubt that it adds a large amount of data to the packages file in practice based on my experience how long it takes to adopt such a feature. My estimation is that we will have to deal with a one liner for about 100 package in the end of 2008 at maximum. If people start to use this information in some tools it is fine. If not we might drop it again as we did with the debtags stuff. Please work on something like Mole/CRMI if you want to associate much more metadata to packages. http://wiki.debian.org/Mole http://wiki.debian.org/CRMI I admit this might lead to a more powerful solution. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposing a new source control header to link to upstream BTSs
On Tue, Mar 18, 2008 at 4:53 AM, Andreas Tille [EMAIL PROTECTED] wrote: Sometimes innovation comes silent. I remember times when we have hidden Homepage information behind 'XCBS-URL'. So why not using XCBS-UpstreamBTS or something like that and experiment with this and see how it might evolve? I assumed that it should start like this, but I guess that asking for opinions on -devel before adding custom fields was expected. -- Martín Ferrari
Re: Proposing a new source control header to link to upstream BTSs
On Tue, Mar 18, 2008 at 5:17 AM, Ralf Treinen [EMAIL PROTECTED] wrote: It would be good if this process could be automated, however I suspect this header is not the solution. Granted, but then you are speaking about giving better tool support for manually forwarding bugs, which is not the same thing as automatically forwarding bugs. Better tool support would of course be welcome. As I said in a previous email, I chose the wrong word, when I said automatically forwarding bugs, I meant being able to instruct the bts command to forward a bug already in the BTS to upstream, probably preparing a boilerplate text and firing $EDITOR, etc. What I want to achieve is having metadata that then can be used by new tools or augment existing ones. -- Martín Ferrari
Re: Proposing a new source control header to link to upstream BTSs
#include hallo.h * Martín Ferrari [Tue, Mar 18 2008, 11:51:45AM]: On Tue, Mar 18, 2008 at 5:17 AM, Ralf Treinen [EMAIL PROTECTED] wrote: It would be good if this process could be automated, however I suspect this header is not the solution. Granted, but then you are speaking about giving better tool support for manually forwarding bugs, which is not the same thing as automatically forwarding bugs. Better tool support would of course be welcome. As I said in a previous email, I chose the wrong word, when I said automatically forwarding bugs, I meant being able to instruct the bts command to forward a bug already in the BTS to upstream, probably preparing a boilerplate text and firing $EDITOR, etc. What I want to achieve is having metadata that then can be used by new tools or augment existing ones. Do that please but keep your fingers off the Packages files. The value of your meta information is not worth the costs of its distribution to every user's local system. Just keep such data available on an visible location like it's done with DEHS, for example. Regards, Eduard. -- weasel Smur: du brauchst nen Level 9 Analyzer Smur weasel: fällt dir da konkret n name ein? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposing a new source control header to link to upstream BTSs
On Mon, 2008-03-17 at 02:38 -0300, Martín Ferrari wrote: Dear -devel: Following the trend to add metadata to the debian/control file that allows for the creation of new and powerful tools, I thought about the usefulness of a header that'd allow to automatically relate to upstream bug trackers. It could be used to automatically forward bugs, track which bugs are open that we don't know about today, and simply to avoid the need to look up manually where should one submit a bug. So, my proposal would be to add two headers that are better explained by an example: Upstream-Bug-Browser: http://rt.cpan.org/Public/Dist/Display.html?Name=WWW-Curl Upstream-Bug-Submitter: http://rt.cpan.org/Public/Bug/Report.html?Queue=WWW-Curl This could easily support systems where submission is by email. And if there's no bug tracking system, the upstream maintainer email could be used, without adding the -Browser header. What do you think of this? I don't see what purpose this has that Homepage: does not, because it is not likely that there will ever be an automated reporting tool. It is just more metadata, and as such, is generally wasteful since it doesn't usually provide anything that Homepage: does not. William signature.asc Description: This is a digitally signed message part
Re: Proposing a new source control header to link to upstream BTSs
On Mon, Mar 17, 2008 at 02:38:19AM -0300, Martín Ferrari wrote: Dear -devel: Following the trend to add metadata to the debian/control file that allows for the creation of new and powerful tools, I thought about the usefulness of a header that'd allow to automatically relate to upstream bug trackers. It could be used to automatically forward bugs, [...] I do not think that automatically forwarding bugs would be a good idea. -Ralf. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposing a new source control header to link to upstream BTSs
On Mon, Mar 17, 2008 at 02:38:19AM -0300, Martín Ferrari wrote: Following the trend to add metadata to the debian/control file that allows for the creation of new and powerful tools, I thought about the usefulness of a header that'd allow to automatically relate to upstream bug trackers. I don't really like that idea, for reasons I state below. I first misread it as upstream VCS, which I do like. :-) I'm happy with the current VCS fields, but it's a pity that it's not possible to fetch upstream's VCS source automatically. It could be used to automatically forward bugs, I don't think bugs should be forwarded automatically. track which bugs are open that we don't know about today, This would indeed be useful, but if automated tools should be using it (like DEHS), a lot of work is needed to parse all those bug systems. If there's a prospect that this work will be done in the near future, then I agree that the fields would be useful. and simply to avoid the need to look up manually where should one submit a bug. This is the main reason I dislike the idea. Users shouldn't need to submit bugs upstream. They use Debian, they submit bugs to Debian, and if Debian (by means of the maintainer) thinks it's an upstream issue, Debian forwards it to them. This means users don't have to put up with registering and learning to use many different bug tracking systems, for example. I think this is important, and would like to have it written down in a somewhat formal way. I hope we can all agree on it that Debian accepts all bug reports, and will forward them upstream if that is what should be done. A user should never hear that's an upstream issue, please report it to them. Given this position, you probably understand that I don't think providing a link to the upstream BTS is very useful for the users. This could easily support systems where submission is by email. And if there's no bug tracking system, the upstream maintainer email could be used, without adding the -Browser header. What do you think of this? It may be interesting information in case the maintainer goes MIA, or something. Most of the time, Homepage should be enough to find it out, though. If not, I think it would be good practise to write it in the package somewhere, but I don't think the control file is a good place for it. Especially given the very minimal amount of packages where Homepage doesn't provide the information (and for those cases, upstream is probably dead, so there isn't really anything useful to say either). Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: Proposing a new source control header to link to upstream BTSs
On Mon, 2008-03-17 at 02:38 -0300, Martín Ferrari wrote: Dear -devel: Following the trend to add metadata to the debian/control file that allows for the creation of new and powerful tools, I thought about the usefulness of a header that'd allow to automatically relate to upstream bug trackers. Please can this 'trend' be stopped here and now? The Packages.gz file is already enormous (especially for Emdebian purposes or other low resource units) and adding yet more fields to debian/control is really not that friendly. Please use debtags wherever possible for all such metadata - maybe even migrate some existing data in debian/control to debtags. This specific request, IMHO, is probably best done via links on the Homepage URL anyway. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: Proposing a new source control header to link to upstream BTSs
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 nn, without you needing to go manually through all the hops that we have to go through today. -- Martín Ferrari
Re: Proposing a new source control header to link to upstream BTSs
On Mon, Mar 17, 2008 at 5:42 AM, Neil Williams [EMAIL PROTECTED] wrote: Please can this 'trend' be stopped here and now? The Packages.gz file is already enormous (especially for Emdebian purposes or other low resource units) and adding yet more fields to debian/control is really not that friendly. I appreciate the strive to make Debian work on small machines, but it is reasonable to put their constraints on the whole project? Please use debtags wherever possible for all such metadata - maybe even migrate some existing data in debian/control to debtags. If I understand correctly, debtags are faceted and not free-form, so you won't be able to enter URLs into it. Other data, like the type of bug tracker, as Russ suggested, could be put in debtags, and it felts like the correct place for doing it. This specific request, IMHO, is probably best done via links on the Homepage URL anyway. Can you explain how you'd do this? -- Martín Ferrari
Re: Proposing a new source control header to link to upstream BTSs
(reply-to as requested) On Mon, Mar 17, 2008 at 5:45 AM, Bas Wijnen [EMAIL PROTECTED] wrote: It could be used to automatically forward bugs, I don't think bugs should be forwarded automatically. See my previous mail, I did choose the wrong word here. track which bugs are open that we don't know about today, This would indeed be useful, but if automated tools should be using it (like DEHS), a lot of work is needed to parse all those bug systems. If there's a prospect that this work will be done in the near future, then I agree that the fields would be useful. I thought about the proposal because I'd like to add this kind of information to the package tracking tool used in pkg-perl (and some other groups) [0], of course I know I have to write the parsers :). Parsing RT and (source|g)forge already covers 99.9% of pkg-perl packages. and simply to avoid the need to look up manually where should one submit a bug. This is the main reason I dislike the idea. Users shouldn't need to submit bugs upstream. They use Debian, they submit bugs to Debian, and if Debian (by means of the maintainer) thinks it's an upstream issue, Debian forwards it to them. No, of course this is not intended for users, but for Debian developers/maintainers/etc. We already have the watch file, which can be related to this idea. Given this position, you probably understand that I don't think providing a link to the upstream BTS is very useful for the users. I agree completely on that premise. But then again, users also don't care about where we host our pakcages' VCS repositories. It may be interesting information in case the maintainer goes MIA, or something. Most of the time, Homepage should be enough to find it out, though. If not, I think it would be good practise to write it in the package somewhere, but I don't think the control file is a good place for it. Especially given the very minimal amount of packages where Homepage doesn't provide the information (and for those cases, upstream is probably dead, so there isn't really anything useful to say either). It is true that having the homepage you can easily find the bug tracker, but I'm aiming at a different goal that what I thing you understood, which is enabling us to write more tools that help _us_. [0]: http://pkg-perl.alioth.debian.org/cgi-bin/qareport.cgi -- Martín Ferrari
Re: Proposing a new source control header to link to upstream BTSs
Martín Ferrari [EMAIL PROTECTED] writes: On Mon, Mar 17, 2008 at 5:42 AM, Neil Williams [EMAIL PROTECTED] wrote: The Packages.gz file is already enormous (especially for Emdebian purposes or other low resource units) and adding yet more fields to debian/control is really not that friendly. I appreciate the strive to make Debian work on small machines, but it is reasonable to put their constraints on the whole project? Adding more fields also increases the time to download Packages.gz, which is an issue independent of the capabilities of the machine downloading it. -- Ben Pfaff http://benpfaff.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposing a new source control header to link to upstream BTSs
On Mon, 2008-03-17 at 12:16 -0300, Martín Ferrari wrote: On Mon, Mar 17, 2008 at 5:42 AM, Neil Williams [EMAIL PROTECTED] wrote: Please can this 'trend' be stopped here and now? The Packages.gz file is already enormous (especially for Emdebian purposes or other low resource units) and adding yet more fields to debian/control is really not that friendly. I appreciate the strive to make Debian work on small machines, but it is reasonable to put their constraints on the whole project? IMHO the Packages.gz file is already too large for my standard Debian machines! Unless you have a v.recent v.fast machine, reading the dpkg available file and apt package lists can take significant amounts of time. Even on this amd64 box, it is a noticeable delay. Why make that worse? Others have already indicated that this particular addition might not be the most useful addition to debian/control - I'd say leave it at that. Please use debtags wherever possible for all such metadata - maybe even migrate some existing data in debian/control to debtags. If I understand correctly, debtags are faceted and not free-form, so you won't be able to enter URLs into it. That's probably for the best, IMHO. Other data, like the type of bug tracker, as Russ suggested, could be put in debtags, and it felts like the correct place for doing it. Agreed. This specific request, IMHO, is probably best done via links on the Homepage URL anyway. Can you explain how you'd do this? ? Ask upstream ? I thought that would be the simplest solution. I fail to see any benefit in linking Debian to the upstream BTS - automated or otherwise and your replies to the other respondents has failed to persuade me that there is any merit in this idea at all. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: Proposing a new source control header to link to upstream BTSs
On Mon, 17 Mar 2008 20:01:30 +, Neil Williams wrote: I appreciate the strive to make Debian work on small machines, but it is reasonable to put their constraints on the whole project? IMHO the Packages.gz file is already too large for my standard Debian machines! I see this point and I agree to it. Maybe a better place for Tincho's idea would be an (optional) debian/bugtracker file (similar to debian/watch). FWIW: The idea of being able to type bts forward 123456 (instead of forward_ed_) sounds really appealing to me. Or an equivalent to uscan like 'ubts'. (And it would need some additional local config for credentials for upstream bug trackers etc.) Cheers, gregor -- .''`. http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4 : :' : debian: the universal operating system - http://www.debian.org/ `. `' member of https://www.vibe.at/ | how to reply: http://got.to/quote/ `-NP: Larimar: Drive signature.asc Description: Digital signature
Re: Proposing a new source control header to link to upstream BTSs
On Tue, 18 Mar 2008, gregor herrmann wrote: Maybe a better place for Tincho's idea would be an (optional) debian/bugtracker file (similar to debian/watch). An important concern is that these sorts of files don't actually change with the source package, they change whenever the upstream changes them. The right approach is something like mole or CRMI instead which is connected with the source package, but changes on its own schedule. http://wiki.debian.org/Mole http://wiki.debian.org/CRMI Don Armstrong -- Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposing a new source control header to link to upstream BTSs
Martín Ferrari [EMAIL PROTECTED] writes: Following the trend to add metadata to the debian/control file that allows for the creation of new and powerful tools, I thought about the usefulness of a header that'd allow to automatically relate to upstream bug trackers. It could be used to automatically forward bugs, track which bugs are open that we don't know about today, and simply to avoid the need to look up manually where should one submit a bug. So, my proposal would be to add two headers that are better explained by an example: Upstream-Bug-Browser: http://rt.cpan.org/Public/Dist/Display.html?Name=WWW-Curl Upstream-Bug-Submitter: http://rt.cpan.org/Public/Bug/Report.html?Queue=WWW-Curl This could easily support systems where submission is by email. And if there's no bug tracking system, the upstream maintainer email could be used, without adding the -Browser header. What do you think of this? 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. Straight URLs pointing to the HTML version of upstream's bug system are probably mostly useful for people, and Homepage should hopefully already give people a reasonable starting point. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Proposing a new source control header to link to upstream BTSs
On Mon, Mar 17, 2008 at 2:38 PM, Martín Ferrari [EMAIL PROTECTED] wrote: Following the trend to add metadata to the debian/control file that allows for the creation of new and powerful tools, I thought about the usefulness of a header that'd allow to automatically relate to upstream bug trackers. 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. -- bye, pabs http://wiki.debian.org/PaulWise
