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
