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

Re: An old idea, brought back to life

On Sat, Dec 19, 1998 at 12:06:35PM -0800, Oscar Levi wrote:
> > I think what you're missing is a change in release philosophy. As it
> > stands now, a release is an all-or-nothing proposition. Packages that
> > aren't ready delay the release of packages that have worked reliably for
> > months. What we could do instead is move packages into stable as they
> > are ready instead of waiting until all of unstable is ready. This is
> > especially useful for new packages, e.g., one that is released just
> > after a freeze, and which might otherwise wait a year to make it into
> > stable.
> Fine.  But, who is to say that moving a package as you suggest won't
> introduce a problem not previously tested.

What if a package is uploaded to frozen now that breaks something?  Same
problem, only that packages have at least a LITTLE time to be tested in
unstable.  Also, people running the pre-release version would have the
opportunity as they do now to download and install select packages from
unstable.  In fact, if we moved this direction apt could aid in this by
allowing greater flexability in installing select packages from unstable.

The way we figure it, there are 3 kinds of users:

* Those who need stability.  They can't afford to have problems that come
  with development and need the system as stable as possible from the
  start and need it to remain stable.  Under both the current and new
  models, they would run stable.  Their only download if they install
  from CD-ROM will be pretty much what proposed-updates is, security
  fixes and dangerous bugs found after release.  In apt you would have
  just stable.

* Those who can afford some bugs that come with development.  They want
  the features ant toys of the newest software, but they can't really
  afford to have something break.  Most non-developers and even a fair
  number of developers are in this group.  I expect a good number of
  developers will be running this to develop on all the time and adding
  things from unstable as they need to.  This will help do what Ben
  Collins wanted and keep people focused on the release more.  These type
  probably run stable with files downloaded out of unstable until
  unstable freezes.  Then they all upgrade simultaneously from stable to
  frozen causing havoc to the ftp sites when we first freeze.  Under the
  new system, they would download incrementally as they do after they
  have moved to frozen.  Or every few months we could release a set of
  snapshot images which those who have poor bandwidth or high cost of
  using the bandwidth can purchase.  In apt you would have stable and
  pre-release with possibly a future apt knowing about unstable, but not
  upgrading to unstable's packages automatically.

* People who want the bleeding edge.  This bunch is not timid.  They
  probably laugh at those running 2.0.x kernels and call them sissies. 
  They want the latest and they'll get it one way or another.  They
  aren't afraid to fix something when it breaks.  These people were
  likely testing Branden's new X packages from -2 or -3 and have probably
  reported countless bugs about them since.  Probably they use unstable
  now, maybe even experimental and download most everything.  They will
  be totally unaffected.

> This is the root of software epistemology.  I AGREE THAT A PACKAGE
> I don't see any difference between unstable/stable and
> prerelease/unstable/stable unless we implement formal testing.  We have
> Incoming now.  We could put the packages some place else before moving
> them into the archive, but then you're play a shell game.

Formal testing is not something Debian can do reliably.  Unless you're
volunteering to be the one to test a good portion of those 2700 packages
I don't see how we can test any better than we do now.

> Verification only makes sense when done in the context where it will
> be run.  Look at the way the emacs periodically breaks.  There are so
> many packages that cooperate with it that it requires repeated
> re-installs to check that the latest combo works.

This should become easier under the new system, but there are always
going to be problems in anything but stable.

> I agree that the present situation has some glitches.  I don't agree
> that adding another archive branch makes sense.

Not adding a branch, changing how we use the ones we have.  pre-release
is essentially a perpetual frozen which packages are moved in to a few at
a time.  When we're ready to release it we freeze it and it's out the
door in a short time, after which packages waiting to go into pre-release
will be moved there and the cycle starts again from the top.

NO ONE expects the Spanish Inquisition!

Reply to: