This is a page intended for brainstorming and outlining useful improvements to Debian as a whole, parts of its infrastructure, its packaging system, etc. If the description of the specific feature gets long, please create a new page and link to it instead and just keep the short description on this page (consider SubPages). You might want to list "dependencies" and potential returns that this feature would provide. It would also be interesting to differentiate the low hanging fruits from the ones that require more work, so -- if you can -- you might want to add a tag like "big effort", "quick", "long term" or a timeframe you think might be appropriate. If you know people interested in working on this, even that could be useful to add.
Upgrade testing with UnionFS/AUFS
After reading a blog post about problems upgrading from Sarge to Etch, it occurred to me that a handy feature would be the ability to run an upgrade test using UnionFS or AUFS to see what problems may be encountered after the upgrade, without actually modifying the existing system. It wouldn't require as much disk space as cloning an entire system, and if the upgrade didn't go well, a simple reboot without UnionFS/AUFS would return the system to the pre-upgrade state. A notable problem would be that data could be modified on the system during the upgrade test (e-mail, database, etc), and such changes would be lost when reverted; care should be taken to prevent mail servers, databases, etc. from accepting changes to their data during testing.
More Debtags support
Debtags is getting mature, and there are now working prototypes of smart search and navigation interfaces. The algorithms are easy. Synaptic and Aptitude should benefit. Mail Enrico for instructions and help.
depends: debtags or libept-dev or python-debian or can be reimplemented from scratch with the data in the Packages file
provides: allows users and developers to find packages with little effort
effort: small to moderate. Most of the effort is in designing how to blend the features into an existing interface, rather than the implementation itself.
interested: Enrico Zini
Reducing boot and shutdown time, dependency/event based init scripts
provides: faster and more consistent system initialisation
effort: medium, partly done (Google summer of code 2006)?
interested: hmh, pere
- Why not use Upstart?
The Debian Desktop subproject is composed now by members of pkg-gnome, pkg-kde, pkg-xfce and others. It has a common project and git repository (debian-desktop-team) in salsa. Debian Desktop has input on desktop and laptop tasks package selection (tasksel project) and is working on common artwork as we speak (desktop-base package).
provides: A better Debian Desktop.
effort: medium, almost done for Etch but will require much more work for Lenny
interested: stratus, firstname.lastname@example.org subscribers.
Single Sign On / Adaptability
We should make it as easy as possible to introduce a new service or a computer in the network, with full access to printers, files etc. There are a lot of different LDAP schemas and mechanisms to give users access to different system services as sound, directories etc. This leads to difficulties to access standard system resources when upgrading the system or integrating a new PC to the network. One example is handing device permissions that removes sound support when upgrading from Debian Sarge to Etch. An other example is to integrate a Ubuntu-based or a Windows laptop on a Skolelinux network.
To improve the features that support this enterprise desktop requirement by harmonising directory settings and working on support for single sign on technology in relevant technology such as KWallet and GNOME Keyring.
provides: Enterprise Adaptability (e.g schools, small and medium sized businesses)
effort: Developer gatherings and coordination with projects as KDM, KWallet contributors and relevant kdelibs developers. GDM, GNOME Keyring, Gnome-libs. Samba, Kolab, Scalix, Asterix, OpenXChange, ?OpenGroupware projects to work on directory harmonisation. Relevant for Linux distributions such as Skolelinux, Debian, Edubuntu, K12LTSP, ?LiMux, mEDUXa, User Linux etc.
interested: KDE developers, Skolelinux <fixme: we need to promote this>
Accessibility is mandatory property for computer systems in private companies and public sector. Blind persons will prefer a text based interface reading the "screen" on a screen reader. Different projects has targeted accessibility that makes it easy for disabled people to use a computer system. As a part of The Portland Project (managed by OSDL) they are migrating the desktop messaging systems to D-BUS to enable cross-desktop interaction. Then KDE and GNOME got an outdated accessibility support. Both GNOME and KDE developers work together enabling accessibility. The support should also be easy to install and use on a Debian based system. Since Debian is one of the major distributions in schools, we could be left out from public tenders if the accessibility support lacks.
provides: Desktop Accessibility "out of the box" for disabled persons
effort: half man year
interested: Klaus Knopper, OSDL, KDE developers, Gnome developers
Development Environment (out of the box)
Developer tool readiness student projects and free software developers programming end user applications in C++ or some other language. It often takes a day or two to configure a developer environment when installing a Debian system. Even if the tools are easy to install with apt-get, some additional configurations has to be done. Then people need 1-2 full days to configure the tools.
provides: LSB developer tools "out of the box" with programming Workbench, Unified Modelling Language tool, project planning tool etc.
effort: half man year
interested: KDE developers, Skolelinux
One Laptop per Child support
The One Laptop per Child project are targeting millions of pupils in development countries. The prototype runs a light weight desktop with full support for video streams and Internet. Memory footprint on the OLPC-device is 128 MB RAM and 512 MB harddisk on flashRAM. Then programs as OpenOffice.org and other "fat" software is out of the question.
provides: Light weight desktop tailored for 6-10 year old pupils
effort: half man year
interested: Skolelinux, Debian developers
Special packages that are language oriented. Each package has its own set of complementary .tdebs, one per each language. This feature was discussed at length during the I18N meeting in Extremadura (Sept. 2006)
All localization information is split from the debs, allowing the binary packages to reduce their sizes to the minimum. The users get only the localization material (.mo files, localized sounds and images etc.) that they choose via specific settings, making localepurge obsolete.
This feature would be beneficial to:
- our users
- only the needed info is downloaded
translation updates could be done after releases (tdebs would have a separate source package after the release - more info on the Translation Debs page), thus translation error fixes and upstream updates could be imported. New translations could be added (is this acceptable for a stable release?).
- translators (lower importance packages, could be accepted easier)
- our mirrors (less traffic since only useful material is downloaded)
RaphaelHertzog: this is not necessarily true, the biggest mirrors are afraid of having many small files to download instead of only some big files. Each new file usually means a disk seek which is costly compared to loading more contiguous sectors from the same file...
- package maintainers (could allow translation package management to somebody else)
provides: split translations, several benefits, see above
depends: multiple changes in apt, changes in dpkg-buildpackage(?)/create a utility to automatically create source tdeb packages from the original debian source package (needed later in order to create separate translation updates), dpkg changes in order to store the translation information (better to be in a separate directory) and associated maintainer scripts; dak changes to support tdebs (which should be in a different area of the archive than the regular debs)
effort: big, maybe could be done for Lenny - needs changes in apt and dpkg need to be though carefully; archive needs changes
interested: Eddy Petrişor, Debian I18N Task Force
Less spammable addresses in Debian
It should be fairly trivial to list in the web interface of BTS and Debian mailing lists non-spammable email addresses instead of the legal ones.
provides: less possibility to be spammed
effort: probably small, 2-3 weeks(?)
This basically won't be implemented in the BTS; see 63995 for details why.
Student DD's in Google internships and Google Summer of Code projects
Match as many large bug fixing and general enhancement projects and student developers as possible with internship and summer-of-code hosts inside Google. Some with traction already:
- kernel hacking and packaging
- automated testing and emulation environments
repository tool development (eg. https://code.google.com/p/debmarshal )
- configuration file management tools
nscd and ldap bughunting and enhancements (eg. https://code.google.com/p/gnscd )
- debian-installer automation
- general bughunting or enhancing any other common free software project
Feel free to suggest/volunteer for/offer-to-host others.
"interested:" Drake Diedrich
Diversions for debconf-generated configuration files
dpkg-divert may be used for regular package files and conffiles, but does not divert files managed by debconf. In enterprise deployments, the required configuration files are often not possible to generate using debconf, and relying on debconf to generate them is unreliable. Supplying exactly what is desired in the file is the desired behavior, but there is no systematic way to prevent a package using debconf from overwriting them.
"effort": A few weeks to create the diversion infrastructure, then many months sending patches to packages to use that infrastructure.
"interested": Drake Diedrich