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

And now for something completely different... etch!

Ok, so sarge has been released! We should all thank the Release Team for
their hard work in putting this major release together. But... how about we
start discussing about what major release goals we want to set for Etch? 

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 

Feel free to add some new items or add (hopefully new) information to the 
ones I list below:

[ Overall improvements ]
- _No_ bugs in base packages (well, at least no old bugs). Base system
  should be upgraded to latest upstream (forward patches!) this includes
  PAM, modutils...
     * Base packages should be co-maintained and maintainers should be
     open to help (not always the case currently)
  See  http://bugs.qa.debian.org/base-full.html
  (Personal note: packages in base packages older than a year should either
  be closed or handled properly, i.e. fixed)

[ Installation improvements ] 
- Firewall configuration during installation (ala Fedora Core or SuSE):
  module for d-i. Currently, the system is exposed just during installation
  on some systems (empty root password?)
- Reduced standard installation (no gcc or development tools!, see 
  #301138 or #301273)
- More "tasks" (grouped packages) for installation: automatic detection
  of user needs and automatic task selection?

[ Security improvements ] 
- Proper package signature checks (apt-secure, currently on experimental)
- Buffer overflow protection: ExecShield or PaX in stock kernel
- Mandatory Access Control support: SELinux support (RSBAC?)
- Possibility to recompile the distro with SPP (apt-build?). New
  i386-spp architecture?
- Proper source code audit by maintainers to detect stupid security
  bugs (/tmp/XX.?? anyone?) Recurrent things like #306893 appear all
  too often. Automatic source code audit ala lintian.debian.org? 
- MD5 / SHA-1 listing of files in ftp sites (useful for forensics analysis
  see #303961)

[ Admin improvements ]
- Possibility to startup the OS in "control" mode: select which init 
  scripts  will run, this provides a way to work-around hardware issues after
  d-i has installed the base system (personal example: #301112)
- 'Status' in init.d scripts (#291148)
- Hardware changes detection: system detects after a reboot when
  a new SVGA card, new Ethernet card, etc. has been installed and prompts
  for new confguration.
- inetd begone! -> xinetd (better mechanism to control DoS, privilege
  separation, etc.)
- Checksecurity -> live up to its name and merge changes from other distros
  and BSDs
- Security / Update managements of multiple servers from a single point.
  There's no single tool to do check the security status of many servers
  at once (like done in RedHat's Network). Use OVAL agents?
  See #253097
- Better OS backup management  -> upgrade rollback?
- Alternate bootup mechanism (dependancy based? see Solaris 10 or 
- Separate runlevels: 2 for multi, no net, 3 for multi no X, 4 for X, 4=5
- Using dpkg as an audit tool to detect changes in the system, not as 
  a security mechanism but to detect broken stuff (includes #155799 and #34194)

[ End user improvements ] 
- Better help/documentation search (dwww sucks, dhelp needs improvement)
  Provide a "Debian documentation center" with search functions to
  detect information in READMEs, html files, manuals relevant to a 
  free-text query?
- Proper User/Sysadmin documentation guides (similar to what RedHat or
  SuSE already provide, not FAQs or HOWTOs)
- I18n documentaion in CD-ROMs, better track of out-of-date translations
- Better package search mechanism (tags?) allowing free text search
  in package management interfaces: "I want a program that does X"

[ 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)
- Remove _all_ out of date dummy packages! (see #308711 and other bugs!)
- Better (not manual!) tracking of bugs associated with testing release



Attachment: signature.asc
Description: Digital signature

Reply to: