On Tue, Jun 07, 2005 at 01:03:12AM +0200, Javier Fernández-Sanguino Peña wrote: > So, without further delay, here's my "Etch-wishlist", it's biased on some > of the things I've personally worked on and would like to keep working on > for etch. I would love to hear the Release Managers opinion on what they > believe should be Release Goals for etch besides the things we all already > know about (non-free documentation purged from main, changes in supported > architectures...) > Feel free to add some new items or add (hopefully new) information to the > ones I list below: Ok, sure. Here are a few one-liners about various things I'm aware of that one person or another wants to see happen in the etch timeframe, together with the name of the person who has claimed responsibility: Toolchain update to gcc/g++ 4.0 - Matthias Klose <doko@debian.org> Switch to dependency-based init.d handling -- Lars Wirzenius <liw@iki.fi> Drop libpng2/libpng10-0/libpng3 packages - Josselin Mouette <joss@debian.org> Drop libmysqlclient10/libmysqlclient12 packages - Adam Conrad <adconrad@debian.org> Consistent LFS support - Steve Langasek <vorlon@debian.org> Bend all library packages to my will - Steve Langasek <vorlon@debian.org> You seem to have a rather long wishlist of your own; are these all things that you personally plan to work on during the etch cycle? If so, kudos! If not, which ones are you expecting to spend your time on, and which are you looking for help with? It would be nice to see more communication still from maintainers when they're planning large transitions in unstable; for instance, GNOME 2.10 started being uploaded to unstable without anyone letting the release team know it was coming, and I'm told there are a couple of places where this might make the toolchain transition more complicated than it needed to be. > [ Release improvements ] > - Prune packages from release based on popularity, packages which are not > used by anyone should not go in! (not enough peer review, probably > not audited, bug ridden with bugs, including security making security > handling a nightmare) It is, after all, quite difficult to determine that a package is not used by *anyone*. You can use popcon to give you prospective candidates, but popcon doesn't prove the package is unused (and, well, a simple statement from the maintainer is counterevidence). That doesn't mean I think you're using the wrong metric; I'm just noting that the payoff for looking for unused packages tends to be very low :) > - Remove _all_ out of date dummy packages! (see #308711 and other bugs!) Ongoing area of work; Jeroen has bumped these bugs to 'serious' now, so they ought to find themselves cleaned up fairly quickly, I think. > - Better (not manual!) tracking of bugs associated with testing release Which we get when version tracking is added to the BTS. Cheers, -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature