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



I'm a little reluctant about speaking with this to this huge
blood-hungry crowd, since this is my first post and I'm starting right
out with something that will be either seen as totally stupid or totally
awesome. In short: this will polarize.

Debian-devel and linux-kernel are both heavily arguing about release
policy at the moment. Arguing in a way they have never been arguing
before. More brutal, more agressive.

I believe that in both cases it's the same problem. The tradeoff between
stability and features. It's hard to tell what is stable and what is not
supposed to be used on production systems yet. This is a problem that
will never be solved. But if you think about it and aknowledge that
tradeoff you might want to use it as a key policy for releases. And:
Isn't "release" actually something stupid: Why do we have to release it?
Who is holding what, so that we have to free and release it?

So why not abandoning releases (distributions in the debian sense) at
all? Can't we have many (infinitely many) distributions at the same


- Lets give each package a new field describing it's stability.  A field
  that - lets say - ranges from 0 to 10 (float?). I think we will find a
  way to calculate that stability (testing has made the first steps
  towards such an algorithm. I'm sure that this algorithm can be
  extended, see below).

- Then let every maintainer upload and maintain as many different
  versions of his package as he desires. I guess that about five would
  be enough for the most packages.

- package-pools is a huge step forward towards abandoning the
  distribution idea. Distributions are now simply masks on top of the
  pool. What they masquerade is determined by such words as "freeze",
  "rc-bugs", "in testing".

- Then simply ask the admin what stability he desires: 0-10

- The dependency system will pretty much do the rest. It can solve all
  the problems like: "a" (available with stabilities of 1,3,5 and
  versions of 1.0.0-1, 0.2.1-1, 0.1.0-2) depends
  on "b" (s=1,4,10 | v=2.0.0-1,1.0.0-3,0.0.2-1) with version of "b" >=
  (2.0.0-1,2.0.0-1,1.0.0-3) [for the respective versions of "a"].
  Now the admin wants stability of at least 3. He wants "a": a_0.2.1-1
  could be installed but depends on "b" >= 2.0.0-1 which has a stability
  of 1. So a_0.1.0-2 and b_1.0.0-3 will be installed. Both fullfill the
  stability ceteria and their dependencies.

Some conclusions:

- This system doesn't introduce more problems. Like the current policy,
  a package that is stable enough for itself wont make it onto the
  system if its version depends on a package which is not available in
  the desired stability.

- Only one thing will go away: The cyclic wave of buzzing, fixing
  rc-bugs and complaining about them. We would have to make sure that
  there is still some motivation to fix bugs apart from the fact that
  there is an upcoming or running freeze!

- Admins would be happy. They could have their own distribution with a
  stability and featuredness they want. No painful decision between
  testing and stable. Wouldn't you be happy if you could take a few
  packages from unstable because of added features and keep the rest 
  from stable because of stability?

- "Incremental (beta/alpha)-testing" would be possible. Isn't it pretty
  much impossible to have a system running "unstable" at the moment.

- In the transition phase (and afterwards too) there would still be
  (cosmetic) distributions, lets say stable (s>=7), testing (s>=5),
  unstable (s>=2) and experimental (s>=0). frozen would disappear.

- We would have to enforce the exactness of dependencies. Has to be done

- There wouldn't be such a big deal with delayed releases and
  forever-taking freezes. They simply dont't exist or happen every
  second depending on the way you look at it.

- Noone would ask for a "strict 6-month-release-cycle". ;-]

Some thoughts about the stability algorithm:

- Added features reduce stability
- Open Bugs reduce stability
- Time in the various lower stabilities without new bugs increases
- Karma of Maintainer increases stability (??)
- What about a voting/rating system for each package where systems, the
  package is installed on, vote for it's stability?

[Yes I know: Define "added features", "increases", "decreases"! This is
the tricky part ;-]

Random thoughts:

- This approach doesn't make much sense for linux-kernel. There is no
  simple way of maintaining the kernel in "parts". But for Debian there
  is. We have dependencies as the only (and natural) relationship
  between the parts.  And the package-pool itself is so much simpler to
  maintain in parts than the entire mess about patches sent around with
  the kernel.

- This is somewhat similar to the moderation idea behind slashdot.

- ... and simply an extension of the testing-idea.

- Space considerations.

- I don't think this is to complex and non-intuitive. Isn't this the
  process, every admin is going through when crawling the internet to
  find a suitable combination of two pieces of software?

- libc: does that make the entire thing impossible because is blocks

That's it.

I know this thing is pretty young. But if more people think, talk and
flame about it...

And: Did I reinvent the wheel?


Man 1:	Ask me the what the most important thing about telling a good joke is.
Man 2:	OK, what is the most impo --
Man 1:	______TIMING!

Attachment: pgpGq7mBhk4zE.pgp
Description: PGP signature

Reply to: