Re: General Resolution: Removing non-free, Draft 2
Josip said:
>
> [Please wrap your lines at <80 characters.]
>
> On Fri, Jun 09, 2000 at 01:59:13PM -0400, paul wrote:
> > > The question is that there is more than one way to follow a standard when
> > > alleviating a problem. And this is the case when a common BTS becomes a very
> > > good thing (TM).
> >
> > I wonder how the Debian based dists (Corel, Storm, etc.) handle this. If
> > there is enough interest among the 0 Debian based dists, then it
> > is possible that a distributed BTS could be developed to track bugs in
> > debs from many different sources. With a strict bug reporting format,
> > such a tool could could determine if a bug is dist specific or common to
> > all participating dists.
>
> You could determine automatically if a bug is distroX-specific for some
> packages, but you couldn't do that automatically for packages of the same
> name and same version. There should be quite a few packages like that in
> distributions based on Debian, since to add functionality to Debian they
> probably didn't have to recompile, increase the revision or rename each of
> our packages.
>
Participants in a distributed bts would need to cooperate in a naming and versioning
scheme as well. with a carefully crafted scheme,
dist specific bugs would evidence themselves as obviously as an inflamed opposable digit ;)
>
> It would be cool if someone enhanced our BTS to be able to send over bug
> reports to another BTS of the same type, e.g. by sending stuff like "distro
> 435675 Debian" to control@bugs.stormix.com, and then debugs BTS on
> bugs.stormix.com would bounce that report (#435675) to the debugs BTS on
> bugs.debian.org, somehow (scp report's files? just submit the whole report
> to submit@bugs.d.o?).
>
> > The long term implications of the GR are unknown, but not necessarily
> > negative.
>
> Yeah, but should we really try to explore that route just because it's
> `a good idea', and ditch the existing practice that we know is positive in
> very many aspects?
>
The point is valid, but a distributed bts would assist in synchronizing
internationalized and localized Debian based dists as well. I know that
there are packages in the Korean Debian dist that are not in Debian. Even
if there is no English version of a particular deb, it would be nice to
know that a "foreign" (for me) language version will work with Debian.
The GR poses a similar problem as internationalization, localization, and
comercial versions based on Debian.
The problems presented by the GR are present whenever another dist is
based on Debian. Why not have these problems addressed by Debian
Developers and maintainers, who we already have a measure of faith in.
I see the proposal in the GR as being a necessary eventuality that,
if properly exploited, could lead to general acceptance of the quality
control standards that Debian is known for, and an increase the number of
packages available via apt-get.
--
ptw
miscelaneous endeavors
(paul@cvanet.com)
Reply to: