Hello,
Regardless of the results of the GR for removing non-free, a few extensions
and changes to the debbugs BTS, as well as to the .deb format and *maybe*
even to some sections of the .debian.org web pages would benefit Debian
users.
These extensions would, as a side effect, mitigate a lot of the
"discomfort" for the end-users should Debian remove support to non-free at
any time in the future, while at the same time being fully generic so as not
to create any sort of "we're still using resources to support non-free
software" replies.
They aim to improve the quality of our BTS and allow multi-vendor .deb
management, no political POV strings attached, by integrating all vendors
who use the .deb format and the debbugs BTS in such a way as to proper
redirect bug reports and (maybe, if technically viable) bug report
inquirities to the proper BTS in a distributed BTS chain, where each vendor
has his own _independent_ debbugs-compatible node.
Many (if not all) of these suggestions were already made by others in the
Debian mailing lists, often in a more detailed or thought out way. I'm only
repeating the basic issues here to remind people there's work to be done
which would benefit all sides no matter the outcome.
Again, I want to stress the fact that these extensions would improve the
quality of our BTS system even if the GR fails, and they would have some use
as of now, since we already have Debian-based distributions out there and
instances of bug reports from Corel or Stormix to the Debian BTS were
reported, I believe.
On the other hand, should the GR for removing non-free be approved, I think
it should be made imperative to deploy these extensions *before* acting on
the GR and removing support to non-free. This way, if other groups want to
pick up the dropped packages, they are theorically able to provide an
acceptable level of user support with minimum hassle for the user.
1. Add Vendor-tracking ability to the .deb format, so as to allow bug
reporting systems (both clients such as bug and reportbug; and the
debbugs server) to track different distributions.
1a. This field must be machine readable (and human readable) in such a
way that the correct debbugs BTS for the package can be selected. It
should be implemented in such a way as not to require any sort of
central management. I suggest the email address domain for the
relevant debbugs BTS system (e.g.: @bugs.debian.org for Debian's
BTS).
1b. This field must be human readable in such a way as to indentify the
distribution (containing a text string such as "Debian", "Stormix",
"Corel Linux", or whatever), maybe including an %-encoded URL to the
distribution's main website (www.debian.org for Debian).
1c. Add such vendor-tracking field to all packages in Debian (woody).
Since such field is the same for all of main and non-US/main, this
could be done in an automated manner.
1d. Fallback to current behaviour if the vendor field is missing.
Provide a default vendor field configuration (might be compile-time)
for the tools which need it so as to make this work.
e.g.:
Vendor: "Debian" http://www.debian.org/ bugs.debian.org
2. Add vendor-tracking and forwarding ability to the debbugs BTS, so as to
make it capable of using the information made available through 1) to
detect whether that package is supposed to be handled by that instance
of the BTS or not.
2a. Forward erroneous-delivered bug reports to the proper BTS AND
notify the user reporting/requesting the bug of the proper BTS to
send the bug reports.
2a1. Maybe redirect bug report inquires to the proper BTS automatically,
if such possibility exists.
3. Add vendor-tracking and multi-BTS awareness to all debian packages which
interface with the BTS. Currently, these are bug and reportbug I think.
3a. Fallback to current behaviour if the vendor-field for the
package is missing or unknown. Select the correct BTS otherwise.
3b. Add a "default vendor" configuration, even if it is a compile-time
#define for 3a) Fallback.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Attachment:
pgpXwhhh9Br_R.pgp
Description: PGP signature