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
> NEEDS TO BE HELD (interpret as tested) BEFORE MOVING INTO THE ARCHIVE.
> 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: