Re: new fields in debian/control
On Mon, 17 Jul 2000, Jim Lynch wrote:
> > and should be merged into a single field
>
> I am not convinced of this.
Well, provide a strong reason for having two fields when they can always
be merged into one. Hint: everything else that uses RFC-822 records uses 1
field were possible, you don't see this in email:
To-User: Jgg
To-Host: debian.org
Related information is always together in the same field.
> > 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:
> Submit-Bugs-Style: RFC-822 # which implies and requires IP and maybe TCP
> Submit-Bugs-To: debbugs://bugs.debian.org
Uh, this is nonsensical.
> What if (gasp) fidonet wants to do this on -their- net?
URIs can contain fidonet network addreses, so I don't see the problem you
are trying to create.
> 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.
Explain to me how you are going to build a shared bug system that does not
run over any network. If it runs over a network then it is indeed
representable by a URI.
> 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
Yes, scheme is what the RFCs call what you have dubbed the 'protocol
indicator'.
> 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.
Uh.. You are talking symantics here, they are functionally identical, mine
is just more in line with accepted practice.
> > 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.
Adam just mentioned to me that newer JitterBugs have email submit
capabilities.
> > 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?
*shrug* Doesn't bother me, I'm just saying we can't expect any old bug
system to work with our systems.
> > 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.
Uh? How can you not see making Corel/etc rebuild all our packages as
anything but bad? How are we going to be a base distribution if everyone
has to rebuild everything just because of one ill thought out field?
> 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 :)
We are the holders of the .deb specification, if we add some kind of new
element to that specification then we have a duty to make sure it is
actually well implemented and useful to the people who are ultimately
going to be using it, and to not just make arbitary changes because they
sound like they might be useful.
> 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.
If anything this supports what I have said..
Jason
Reply to: