Mark Howard <[EMAIL PROTECTED]> writes:
> My initial thoughts were that many minor bugs and wishlist items as well
> as a general unpolished feel should stop a package getting into stable.
> There are many reasons, however for including galeon.
>
> Should we have another measure for when packages are releasable in
> addition to RC bugs. For example, does having >100 minor bugs means that a
> package is unsuitable for stable?
> I know the default answer is that it's the package maintainer's decision
> - but I don't know what to decide! Also, saying <200 non-RC bugs might
> be a useful QA metric.
Have you counted bug on some packages? dpkg, glibc, xemacs, gnome, kde
come to mind.
Should we delay the release till dpkg2 is ready?
I don't think the criterium would be very usefull. Most packages are
small, they never get 100 bugs without getting a RC bug or (should be)
orphaned.
Others are huge complicated beasts and get tons of bugs no matter how
much work you put into ot how good they work.
If you feal a package has too many bugs you should offer
co-maintainership, find someone to co-maintainer, hijack the package
or get it orphaned/removed. Even adding a RC bugs "too many bugs, keep
out of testing" might be a good idea if testing has a reasonable
working version.
MfG
Goswin
