Hello! On Sam, 05 Jan 2002, Robert Jördens produced 5,8K chars torturing the keyboard: > And: Did I reinvent the wheel? I guess, I did. It was: 30 Aug 2000 - 31 Aug 2000 (10 posts): Crazy idea: removing version numbers from debian But then: Lets bring it up again. My idea is much more far reaching ;-] - Can't we have the one without losing the other? I mean having those floating releases and on top of that officially announced and promoted releases (may be even every 6 months or oriented on different release goals). Times or goals as distros is so much similar to stable,unstable,testing on top of package pools. - What do statistics about the CD/FTP ratio say? Are CDs still so important, that we need definite and long-lasting identical images/distros? True: floating release is nothing for CDs. Having 5 different versions of a package on each set of CDs is not very productive. [But then again: We might become the first distro that only fits on 5 DVDs. That would make us the "largest distro in size" for ever. ;-] - What if the need for stability increases on a system (the stability-value of the system increases or the stability of a packges version decreases because a bug is found): Is a downgrade in version and upgrade in stability of a package a big deal? Is this a problem? Or isn't this rather something we _have_ to support better anyway, because it happens too in real life if you build/install from source and maybe discover a bug and then downgrade? - Support: Should not become more complicated because we are already supporting different versions of a package and different "clusters" of interdependent packages at the same time with stable/frozen/testing. The BTS is prepared. The archive is prepared. - "Synchronizing the dependency graph globally": Isn't that already done with correct and versioned dependencies and the stability-value. - I believe that we really need the stability-value anyway. Although this will be really tough, a clear mathematical definition of stability is needed everywhere. At the moment we have a pretty sloppy and fuzzy one: Personal opinion of archive maintainers (time of upload, no new features but bugfixes), number of bugs and time for testing. - I don't know the process to well yet. But AFAICS the following things would have to be done: + Add the "Stability:" field to Packages.gz (for the pool). This is the only place it belongs. We don't want to poke into the binaries every time a bug is discovered. + Discuss, write and set up the rating system. + Remove that distribution field in debian/changelog and .changes Isn't its role fainting with package pools anyway? + Make apt/dpkg aware of the field, its implications and write a frontend to the desired stability-value. + Reorganise the archive. Set up distros as symlink-collections to depending on stability and time. + Reorganise the upload process. And yet again some thoughts about the rating system: - Anonymised (!!!!) registration of every installed package on systems wich install from the net should not be to difficult (Yes, on a voluntary base; registering its usage is more difficult - and I don't want it for my systems; or simply take it from download statistics). Then we have something like a machine_installation_days variable for the packages. This alone would have huge implications but would give us a rough figure about usage. - Maintainers must be "honest" about added features and fixed bugs. Add something analogous to "Closes: Bug" ("Opens: Feature" ?) to the changelog. "Severity" of added features? Inverse BTS (FTS)? Funny idea. - We would have to take initial Stability values from the distro a version is in. - The rating of stability is a problem. ;-] Robert. -- Cult of Aloneness: The need for autonomy at all costs, usually at the expense of long-term relationships. Often brought about by overly high expectations of others. -- Douglas Coupland, "Generation X: Tales for an Accelerated Culture"
Description: PGP signature