[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: And now for something completely different... etch!

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.

Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature

Reply to: