Differences between revisions 32 and 33
Revision 32 as of 2005-06-14 08:58:16
Size: 17381
Editor: anonymous
Comment:
Revision 33 as of 2005-06-14 16:49:03
Size: 17383
Editor: anonymous
Comment:
Deletions are marked like this. Additions are marked like this.
Line 128: Line 128:
 * [http://lists.debian.org/debian-devel/2005/06/msg00729.html Harmonize, internationalize output of initscripts] (verbose as default and/or simple as ["ok"]/["notok"] (ok, this is really needed only on a desktop, in production you are supposed to read and debug error messages yourself))  * [http://lists.debian.org/debian-devel/2005/06/msg00729.html Harmonize, internationalize output of initscripts] (verbose as default and/or simple as !["ok"]/!["notok"] (ok, this is really needed only on a desktop, in production you are supposed to read and debug error messages yourself))

TODO for Etch

This is intended to be a TODO list to track:

  • changes that people would like to see implemented
  • changes that are taking place
  • changes that have taken place

between the release of Sarge and the release of Etch.


Table of contents

  • Guidelines
  • Background information
  • Proposed changes
    • Policy application
    • Large software updates
    • Package additions, removals, replacements
    • Distribution infrastructure
    • General issues which affect several packages
    • Service init and management
    • Security enhancements
    • Documentation, internationalization, localization
    • Improvements


Guidelines

Here's a few simple rules to keep the discussion on topic:

  • Don't list issues with single packages here - we have the bug tracking system for this! http://bugs.debian.org

  • Don't list proposals here on how the Etch release should be managed. There is ["ReleaseProposals"] for this.

  • For all issues, please try to provide links to mailing list discussions etc. - while the Wiki is good for keeping track of issues up to some point, it is not a good discussion medium imho. So, if you list controversial issues here, DON'T discuss these things here and don't just remove them - add links to relevant parts of the mailing list archives.

  • If you know that a particular change is done already, please clearly mark it so and provide links.


Background information

See [http://udu.wiki.ubuntu.com/UbuntuDownUnder/BreezyGoals the goals for Breezy] for a list of new features in the next ubuntu and how far they got with implementing them.

Proposed changes

Many of these proposed changes are from the "[http://lists.debian.org/debian-devel/2005/06/msg00462.html and now to something completly different... etch!]" and "[http://lists.debian.org/debian-devel/2005/06/msg00979.html TODO for etch ?]" threads in the debian-devel mailing list archive.

Policy application

Large software updates

Of course packages are continually updated as new versions are released. The goal here is rather to list the large migrations which have wide ramifications for the distro (e.g. switch to a new X server, not update minesweeper from 1.8.9 to 1.8.10).

Package additions, removals, replacements

Distribution infrastructure

General issues that affect several packages

  • Get rid of all non-debconf questions and similar stuff. Get rid of useless debconf abuse.
  • [http://lists.debian.org/debian-devel/2005/06/msg01025.html Fix packages in base and packages up to priority standard so as not to use savelog]. There is at least one package in base i know off which uses savelog to rotate logfiles. Using logrotate is a more save way, as it gives the user the possibility to configure more easyly when logfiles are rotated. I would like to see 5(j) of etch release-policy adjusted or best, to say, all packages must use logrotate.

  • [wiki:?["IPv6"] http://lists.debian.org/debian-devel/2005/06/msg01025.html Make packages in etch handle] There are still a bunch of packages which are not ready.

  • [http://lists.debian.org/debian-devel/2005/06/msg01025.html Document tcpwrappers usage in all packages] A lot of programms use tcpwrapper which I appreciate a lot. However, it is quite often not too easy to find out what to write in hosts.allow to allow access to exactly that program. Frankly speaking, having that information always in the manpage seems a good idea to me. (i would like to see that as recommondation for packages in etch)

  • [http://lists.debian.org/debian-devel/2005/06/msg00501.html Reorganize packages] that have been postponed over several releases; e.g., #100332: "tetex-bin: please move xdvi to its own package"

Service init and management

Security enhancements

Documentation, internationalization, localization

Improvements