I have a Debian wish for lenny:

• define and deploy a standard way of packaging software, that can be used for like 90% of packages. (It doesn't 'have' to be CDBS, it can be something 'better' for a reasonable definition of better. CDBS is the closest of the packaging tools I've tried so far, I've had single line package scripts with CDBS for many packages)
• Put the maintainer scripts into version control, it should be something with a central repository, but that of course allows maintainers to easily do a local branch. Especially for backports. Maybe SVN with SVK is okay.
• Use a standardized patch system along with a toolchain, quilt-like
• Link this patch management to upstream watching, so that patches applied upstream can automatically 'disappear'

Why do we really have to make a distinction between NMUs and maintainer uploads? I agree that we need to have someone (which can be a group) be responsible for packages and need to keep track of that to detect unmaintained packages (as well as to have someone track bug reports).

With this central repository, we could have NMUs committed to the packages directly, and make contribution easier in general.

For example, right now transations are usually added to a package via a bug report. The maintainer then needs to go through these bug reports (and some packages have so many open bugs I doubt the maintainer has a real overview over them; so he might easily miss some easy to fix ones), extract the patch and apply it to his package after review. With this central patch tracking system, the translators could just commit the translation change to the package directly, and it will end up in the next upload automatically.

(Note that I'm not trying to force all packages to be maintained this way. I agree that for some packages it's not really appropriate. In general it should be left to the maintainers discretion. However I guess many team-maintained packages are handled in a similar way already, and I'd like to use that for my packages as well, even when not having Co-Maintainers. I'm also aware that when fixing security issues, you might not want to make your changes world visible immediately. This can however be done using SVK if we end up using SVN, for example.)

Some rationale for this suggestion:

• Promotes team maintainance
• Offers another easy way of contribution (especially for sponsorees)
• Better change and version tracking
• Standard way of packaging makes NMUs and adoption easier
• Makes it easier to work on many packages when needed (e.g. new GCC version fixes, porters, translations, upstart support, SELinux support, Python, all kinds of transitions)

In fact I think that other distributions (e.g. *BSD ports, Gentoo?) are ahead of us in this respect, having a standard way of packaging and building things and keeping track of changes.

Anyway, just my € 0.02

[Yes, I'm aware that this was covered in the DPL debate, but IMHO the point of different packaging preferences falls a bit short, and probably needs to be addressed first, before being able to have a central VCS for all packages. Also I think we should be able to find a common VCS we can all live with, or at least 90% of packages.]

[And yes, I'm aware that this is a controversial topic that can easily start yet another flameware. But we need to find a way of keeping flamewars down anyway...]