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"
pgpbYWWX3gUZ1.pgp
Description: PGP signature
