Re: An old idea, brought back to life
Joseph Carter <knghtbrd@debian.org> wrote:
> The way we figure it, there are 3 kinds of users:
The following would be very good as documentation (orientation,
suggestions, whatever) for new users. However, a few nits: this is
about systems, not about people. Also it's a spectrum -- someone might
have a system which runs unstable till they get burned, then back off
for a while till they need some wholesale change from unstable again.
And some who need stability might even be reluctant to upgrade to a more
recent "stable" -- especially if they have significant locally installed
software which isn't properly registered in dpkg's database.
Personally, I've got systems in most of these categories (except for
the rabid side of bleeding edge).
[Repeated for convenience and to make it obvious what I'm talking about]:
> * 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.
Eh? There's a lot that can be done with `make test`. This should happen
before the .deb is even generated. If we had a few test machines we
could do some basic configuration testing as well (like: install it
on on a minimal system and check for basic functionality, install it
on a maxed out system and check for basic functionality). We'd need a
debian script to verify functionality on a per-package basis, and we'd
initially have to punt on a lot of things, but this is doable.
> This should become easier under the new system, but there are always
> going to be problems in anything but stable.
Agreed. But there's still lots of room for improvement.
--
Raul
Reply to: