Hello!
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
time?
Meaning:
- 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
anyway.
- 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
stability
- 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
everything?
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?
Robert.
--
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:
pgp67k4n1cEyZ.pgp
Description: PGP signature