Re: new fields in debian/control
Hi,
> Date: Mon, 17 Jul 2000 01:29:18 MDT
> To: Wichert Akkerman <wichert@cistron.nl>
> cc: debian-policy@lists.debian.org
> From: Jason Gunthorpe <jgg@ualberta.ca>
> Subject: Re: new fields in debian/control
>
> On Sun, 16 Jul 2000, Wichert Akkerman wrote:
>
> > * Origin
> > This lists the origin of a package. For all Debian packages this should
> > be `Debian'.
>
> This matches what is defined for the Release file..
>
> > * Submit-Bugs-To
> > An mailto URL to which bugs should be submitted. (It's a URL so
> > we can support other types of BTSes at a later date if needed)
> > * Submit-Bugs-Style
> > Style in which submitted bugreports should be formatted. Currently
> > the only option here is `debbugs'.
>
> IMHO both these are badly named
Maybe...
> and should be merged into a single field
I am not convinced of this.
> called 'BTS', or the longer 'Bug-Tracking-System'. This follows how all
> other RFC-822-like systems work. The value of this field would be a URI,
> eg:
Then
Submit-Bugs-Style: RFC-822-debbugs
or
Submit-Bugs-Style: RFC-822 # which implies and requires IP and maybe TCP
Submit-Bugs-To: debbugs://bugs.debian.org
because you -know- someone's gonna
come up with something new later.
What if (gasp) fidonet wants to do this on -their- net?
> BTS: debbugs://bugs.debian.org
> BTS: bugzilla://bugs.mozilla.org
> BTS: gnats://bugs.gnu.org
> BTS: jitterbug://bugs.samba.org/bugs/
>
> The scheme tag indicates the access scheme which must have well defined
> semantics. debbugs means bugs are submitted to submit@address, lookup
> for package bug lists is done with http://address/package, etc. jitterbug
> would indicate web-submittal using the jitterbug system at
> http://bugs.samba.org/bugs/. The double // is included because the URI
> must always specify an internet host.
Must the host always be on the internet, btw? I note that the linux kernel
allows the IP protocol to be -removed- entirely. Not usual! But not
disallowed. Hence, more powerful means (including the out-of-band style
indicator) needs to be allowed, imo.
By the scheme tag, do you mean the protocol indicator of the uri? Whether
only URIs are allowed in that field or other kinds of BTS specifiers are
also permitted, I contend (as in my last msg) that a style indicator can
usefully be made separate. I contend so because it's cleaner, more readible,
more maintainable and allows for more possibilities.
Your tone suggests it's the only way (or, the only good way) to go; I think
the future holds more possibilities.
> All schemes must have well defined automated access methods, preferably in
> a written specification someplace. [this rules out jitterbug AFAIK]
OK, then no matter how this goes, we should suggest to the jitterbug folx
that it would be good for them and their users if they come up with same.
Therefore, the request should probably be made today or at least very soon.
> It should also be made clear that the given BTS must be specifically for
> tracking .debs,
Wouldn't this be limitation of field of endeavor? What if the bts
-wants- to track more than just .debs?
> not a general BTS like Mozilla's - and more
> importantly the BTS field for all debian distributed packages
> must be set to out BTS and not upstream's for that package.
>
> This field should also be included in the Release file, I will update the
> Release file document when this is properly decided on..
>
> Now, aside from that - it is not entirely clear to me that this is even
> the best way to go. In fact, I think it may be quite harmfull.
Why?
> Consider, if Corel distributes Debian + Their Junk they will want to get
> bug reports for the whole thing not just their packages. Having them
> rebuild all our stuff just to change those fields is not entirely good for
> them - or us.
I'm waiting for the other shoe to drop here... all you are saying is
"consider this situation" then "this is bad", without saying why. Please
make your reasoning explicit so I can see.
> The same basic argument holds for all commercial users of Debian, they
> will always want bug reports to go to their support staff, not ours.
And my above argument must hold here too. Please say why.
I contend that decisions of this kind rest in the hands of the respective
organizations, the same way I would contend that Debian has little or no
business making unchangable decisions in the area of someone else's
installation. I'm not saying debian is guilty of making them at this point,
just that if they did, sysadmins everywhere would go crazy :)
> It would be considerably better if there were some way for dpkg to be able
> to store information from the Release file when installing a package, that
> way things like the BTS are tied to the download location, not to the
> person who created the .deb.
Are you saying they should not be allowed to handle bugs for anything in
main? I think the opposite, because this would be a restriction on field
of endeavor: if forks want to be able to handle their own bugs, by all
means, let them. But if they do that, they should not be allowed to boast
debian name or quality.
Maybe if they fork, they have to alter the maintainer field to also point
at their staff.
Maybe it would be bad for them... at 4000 pkgs and up, I wish em luck :)
But it should be their choice to try, and their choice as to what network
protocol they run over their wires.
-Jim
---
Jim Lynch Finger for pgp key
as Laney College CIS admin: jim@laney.edu http://www.laney.edu/~jim/
as Debian developer: jwl@debian.org http://www.debian.org/~jwl/
Reply to: