Re: Development standards for unstable
On Thu, 12 Jan 2006 14:23:31 +0100, "Thomas Viehmann" <tv@beamnet.de>
said:
> Hi,
>
> first of all, thanks for taking the initiative I think the matter is too
> important to be left alone just for avoiding to step on anyones toes.
>
> Anthony Towns wrote:
> > Random ideas for negative consequences might include forced
> > orphaning by overriding maintainer fields to debian-qa, removal of
> Maybe this should not only be limited to packages with RC bugs... For a
> lot of packages with inactive maintainers, it might be best to not
> release them in etch.
Unlikely in general at least. A lot of buggy packages work and are
being
used by people, so dumping them outright is probably not going to work.
What we might try is making the BTS info even more accessible by somehow
integrating it with synaptic or dpkg. The BTS record is one of the most
important peices of information about a package and isn't available for
browing directly from synaptic.
At some point we're also going to have to face the fact that the current
package-the-world-then-fix-every-rc-bug-in-it approach doesn't scale
arbitrarily. With the current definition of RC bugs (including security
holes, data loss, and breakage of unrelated packages), we will
eventually
be in a situation where we have packages that we don't have time to fix,
but aren't broken enough that the few users who have been using them for
years will be best served by our dumping the packages. If we had a way
to flag such packages 'deprecated' or
'very-buggy-your-on-your-own-if-you-try-this-one' (obviously we'd have
to
think of some better names :) it would prevent new users from being
misled
into trying the package without inconviencing existing users.
Britton
>
> Kind regards
>
> T.
> --
> Thomas Viehmann, http://thomas.viehmann.net/
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
>
--
Britton Kerin
bkerin@fastmail.fm
Reply to: