Re: Development standards for unstable
"Thijs Kinkhorst" <firstname.lastname@example.org> wrote:
> On Thu, January 12, 2006 14:23, Thomas Viehmann 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.
> While the package might not be of the quality we strive to achieve within
> Debian; if a bug is not release critical we consider the bug not to be
> serious enough to impact the packages' releaseworthyness. This is by
> definition. Even if there are many of those bugs, they appearently do not
> prevent the core functionality from working.
> I very much agree that we should strive to make packages as good as
> possible, but if users depend on a package and there are no real
> showstoppers in it, we might do our users a better service with shipping
> than with not shipping the package.
Well, that depends on which kind of package it is: If the package is
mainly a dependency of other packages, or something with a long history
(like texinfo which was unmaintained for months if not years until
Norbert Preining took it last autumn), you are right.
But if a rather new package in active development has many non-RC bugs,
some of them crippling upstream features, and one of them "New version
N.m.o available" (retitled three times meanwhile), then our users are
probably better served by telling them "We can't provide a properly
integrated package, please install it into /usr/local".
Inst. f. Biochemie der Univ. Zürich