On Sat, Apr 02, 2005 at 06:08:52AM +0200, Adrian Bunk wrote: > On Fri, Apr 01, 2005 at 06:56:45PM -0800, Steve Langasek wrote: > > On Fri, Apr 01, 2005 at 07:59:01PM +0200, Frank Küster wrote: > > > Jeroen van Wolffelaar <jeroen@wolffelaar.nl> wrote: > > > > On Fri, Apr 01, 2005 at 07:28:35PM +0200, Frank K?ster wrote: > > > > Right, but open for 47 days already. If for this amount of days an RC > > > > bug is open and nobody seems to have cared enough to fix it or even > > > > provide a patch, I think it's justified hinting it out of sarge. > > > You are probably right. However, removing a package should not be done > > > without > > > - adding a note about this to the release notes (Is there a package or > > > pseudo-package for the release notes now? I don't think so). > > There is an upgrade-reports package, but not a release-notes package. > > Perhaps upgrade-reports is good enough for the moment, since removed > > packages are upgrade issues? > > Anyway, packages are removed from testing or unstable+testing all the time > > when they're not releasable, without necessarily looking at whether they > > were present in stable; and many of these may get back into testing before > > release; so it's not really practical to track removals until we get close > > to freeze (like, hmm, now). > >... > This still catches only part of the problem. > I wouldn't assume that the majority of Debian users completely reads the > release notes. Then we should first tell them about how to use aptitude (or other tools) to track and manage obsoleted packages on their system, and only second list the individual packages that are removed so that we don't tax their attention span. AIUI, the release notes are defined as "things you need to know about this new release." I don't think we should be encouraging a culture where users ignore such things and blame us afterwards; and I don't think we should sacrifice the release schedule for transition packages for buggy and removed software just to protect users from things they shouldn't do. IOW: this is important, but not RC. > Consider someone discovers a remotely exploitable hole in wwwoffle > 13 months after the release of sarge. > According to the Debian Popularity Contest, 1.5% of the Debian users run > wwwoffle. > Consider one third of them completely read the release notes and removed > wwwoffle. Then one percent of all computers running Debian 3.1 will be > vulnerable - and there will be no DSA warning them. > You can argue "it was documented" - but the number of vulnerable > Debian 3.1 machines will still make the script kiddies very happy. > And wwwoffle is only one of many removed packages. How many transition packages can I put you down for, and when can we expect them to be delivered? > > The release team doesn't remove packages from testing for reasons that don't > > go through the BTS, and these are generally documented in > > http://ftp-master.debian.org/testing/hints/ as noted. > That's wrong. > The release team does remove packages for getting library transitions > into testing. If a package affected by the transition depends on a third > package that is not yet ready for testing, it might be hinted for > removal by the release team without any mentioning in the BTS. True, those removals don't get mentioned in the BTS; but they are either a) transient, with the release team taking responsibility for getting the new version of the package back into testing, or b) discussed with the maintainer. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature