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

Re: Theory


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

- 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

- We would have to take initial Stability values from the distro a
  version is in. 

- The rating of stability is a problem. ;-]


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

Attachment: pgpEs2hamy0Su.pgp
Description: PGP signature

Reply to: