Which packages will hold up the release?
You might ignore this comment...
Looking at the list of RC bugs the packages seems to fall in two
categories. Packages I don't use and packages I don't feel comfortable
in touching (glibc being an example of the latter).
I don't know the reason for some packages being marked [REMOVE] but it
seems to me that it is not just an 'This package is not essential for
a releas an useful distribution'. For an example I don't guess that
gkrellm-alltraxclock is in any way a package that people think
should really hold up the release.
0) Sorry, just a random pick.
There are some packages we should have if we want Debian to be a
general purpose distribution. I guess we can have a long flamewar
about which packages this includes and in the end it is the release
manager's decission but it is probally something like:
- whatever in the Base Utils-section
- Mozilla (some sort of)
- Emacs (some sort of)
- VI (some sort of)
- ... And then some pacakges I've forgot...
And then depencies and build-depancies for these packages is needed
too. Has anyone tried to make such list of packages we can't release
without and made a list of RC-bugs in excatly those packages?
I believe this is the bugs it would be most effective to actack when
the packages I'm personally directly interested in. It can be hard to
look at the RC-list and decide if the time is better spend fixing
libtse3, libvorbisfile3, or fam.
A script that reads packages I'm interested in and prints out the
RC-bugs I should try to fix would be usable. Does anyone have such
Is this an egoistic approach to fixing RC-bugs? Yeah, and so what?
- it is the best possible motivation I can think of.
You might as well ignore this comment too...
I really shouldn't send this mail. It will probally just (re)start
some flamewar. Let me have the illusion that the time spend flaminig
wouldn't have been used on real development otherwise.
Peter Makholm | If you can't do any damage as root, are you still
email@example.com | really root?
http://hacking.dk | -- Derek Gladding about SELinux