On Sun, May 31, 1998 at 12:55:20AM -0500, David Engel wrote: > I agree that standard and important should probably be combined into > just standard. Prolly, yes. > You sort of suggested that the dividing line between core and non-core > packages probably lies between the current optional and extra > priorities. Upon further thought, I think it might lie somewhere in > the middle of optional. Either way, what then would be the harm in > moving the extra packages to contrib? Only that Contrib means "Depends on non-free software"... > > The first group wants to always have the latest of everything, regardless of > > testing level or absolute stability. This includes a fair number of the > > Debian developers, and some of our more wild-eyed friends, but isn't the > > mainstream. This community can be reasonably assumed to be net-connected, > > and probably cares about CD'd only when they're doing a cold install. > > The group is served fine with the unstable tree. It works. => I will admit to being somewhat part of this group. I'm somewhere bewteen here and the third. > > The second group is CD-focussed. They are either folks who aren't on the > > net with lots of bandwidth, or who are using Debian to provide the platform > > for other work, and don't want to be "bothered" by constant change. For these > > folks, a fresh CD every half-year or year is good, and it's important that > > the bits they get be as robust and bug-free as possible. Once they install > > a package, they're making a long-term committment to that package revision. > > This group hasn't historically been served well by Debian. This group hasn't historically been served well by Linux. Linux itself is a big moving target and drivers aren't modular enough now to be included with hardware. If you upgrade hardware, you can bet you'll need a new kernel at least. > > We think the third group represents the primary target market for a > > distribution like Debian. This group has good net access, wants to stay > > reasonably current, but can't tolerate dealing with the worst 10% or so of > > the package churn that happens in a bleeding-edge "unstable" tree. They would > > prefer not to bump into any real problems, but they're willing to stumble once > > in a while if that's the price of keeping up with security patches, new > > development tool releases, and the like. This group might be characterized > > by those who are currently running 'hamm' on production servers, as we do at > > work. > > I'm not sure that I would consder this group as the primary target for > Debian. Regardless, as long as there isn't another major change in > libc, I think this group could be served just fine with the unstable > tree when combined with liberal use of dpkg/dselect's hold (i.e. > don't upgrade) feature. dselect's hold feature is brain-dead and is ignored everywhere but in dselect. High hopes for apt. And the lack of frequent update CDs makes me a little uneasy about using the unstable tree. I do because I have the most essential stuff backed up, but it would hurt lots if I lost my drive for some reason. I plan to order hamm on CD as soon as hamm is there on CD to order. > > The insight we had was that for this third group, formal testing is icing on > > the cake, and not really required. If we were to implement a "package pool > > with symlink trees" approach such as I described yesterday, we might envision > > training our automation not only to routinely build a symlink tree of the > > latest versions of each package for the first group, but also to build a > > "stable but unreleased" tree for this third group. The key concept is that > > That's an interesting approach. I wonder how well the "stability > implied by package age" approach would work out in real life. It wouldn't. If you were gonna do a "stable but not yet released" tree similar to bo-updates packages would need to be moved in to it as the packages became stable. I've described how I can see this working a couple of times, the gist of it is that after a time if there aren't any stability affecting bugs you can call the package stable if everything else the package depends on etc is stable. If there are after that time open serious bugs, the package can't be moved to stable till they're closed/downgraded as appropriate. > I sincerely hope, and mostly believe, that Debian won't have to deal > with such a major change as a libc replacement again any time soon. > That being the case, I don't think we should dwell any further on how > that affected the delay in Debian 2.0 who to prevent it from happening > again. What about glibc 2.1? => <hides>
Attachment:
pgpxOV5aQvZBw.pgp
Description: PGP signature