My ideas for a DPL platform

cazzeggio debian eng pdo

I regret I didn't candidate because this year I have great ideas for a DPL charter. Here's a list.

Debian press

No more people in charge of press: we replace it with a polygen grammar generating press messages, and we run it once a week.

This way we won't have the problem of a silent press team, and Debian will be a steady, rocking voice in the world of Linux distributions.

This will solve visibility problems compared to Ubuntu, where people perceive that Ubuntu is more important than Debian because they make more frequent and flashy press releases.

Debian releases

Whenever the autogenerated polygen press message will mention a new release, we immediately release.

This will allow Debian to finally release early and often like a good Open Source project should do, and still won't make us give up the unpredictability of the release cycle that makes things interesting and fun.

Security support

This goes in two steps:

  1. By correctly designing the frequency patterns of the Press polygen grammar, we can tweak the mean time between releases to be about a month.

  2. We increase the quality of security support we offer to our users by supporting release updates for both stable and oldstable.

This means having to do security support for a package for no more than 2 months, and would greatly ease the workload of the Security Team.

Migration of packages into testing

The migration procedure of a package into testing needs to be changed. In particular, every version of a package which is a suitable candidate for testing must be manually approved by the maintainer using a non-obvious procedure. Say, send a cryptographically signed mail to a bot that will reply with an encrypted mail with a one-shot web link to a page requiring Java to log in so that you can't set your browser to remember your password. And instructions written in very long complicated phrases by a literate Italian and then translated into English by a literate German.

This will ensure that only maintainers motivated enough to maintain good quality in their packages will have them transitioned to testing, and ultimately in the stable release.

In case of maintainers who are MIA or don't care about their packages, then the damage they would cause to the stable release would be drastically limited.

Version numbers

As a GNU/Linux distribution, we have a duty to protest against the new crazy versioning scheme adopted by the Linux Kernel. For that purpose, I propose to adopt a new versioning scheme for our releases (and possibly for our packages as well).

The idea is simple: replace numbers with names of fruits and vegetables, properly alphabetically sorted. Such as:

  1. Artichoke
  2. Banana
  3. Carrot
  4. Dates
  5. Eucaliptus
  6. Fig
  7. Garlic

...and so on.

Etch release would then be "Debian GNU/Linux Etch 3.Banana".

This would also help when choosing an alternative logo for the release, in case the release name summons only bad ideas like it happened with Sarge.

In case one has to choose among various fruits and vegetables with the same initials, please prefer the ones that are in season at the time of the release.

Flamewars

Flamewars are easily solved by approval of this extra-reduced community guideline:

  1. If you think that mailing list are unpleasant, stop reading them for a while and fix some bugs.

  2. If you think mailing lists are lots of fun, chances are that you're wasting too much time on them and you should fix some bugs instead.

The simplicity of these guidelines also makes them easily enforceable with a simple algorithm: