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!
Description: PGP signature