Re: so what? Re: Debian development modem
On Sat, May 30, 1998 at 01:04:41AM -0600, Bdale Garbee wrote:
[This part re-ordered for clarity]
> While we were talking, another thing that was really clear to us was that
> 'standard' and 'important' should be merged, leaving the name 'standard' for
> the combined priority. That would leave 'required' as the set of packages
> that are part of the base install, 'standard' as all the stuff that one might
> reasonably expect to be present on any normal Debian system, 'optional' as the
> place where most packages live, and 'extra' for the kinds of things that get
> shoved out there now... dangerous toys, etc. Once we get past this
> constitution thingy being ratified, I intend to propose this officially.
I agree that standard and important should probably be combined into
just standard.
> : If I understood another message correctly, the test team has
> : only recently finished checking out the required and important
> : packages, now hopes to check out all of the standard packages and
> : probably won't get to the optional and extra packages at all.
>
> If we were to beef up the documentation of what the priorities on packages
> meant, and made it clear that there was a descending scale of promised quality
> for priorities farther from 'required', I think we could take care of most of
> the problems you're identifying. Yes, there will always be some user unhappy
> about a bug, or a package that goes orphaned... but dwelling on that may be
> counter-productive.
I think you are overestimating the ability of many users to recognize
the subtle distinction between package priorities.
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?
> I had an interesting chat with one of my cohorts at work today about this
> topic. We spent some time thinking about the various Debian users we know,
> and tried to characterize what they want from the distribution. What we came
> up with was the notion that it splits three ways.
I think your characterization of users is accurate.
> 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.
> 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.
> 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.
> 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.
On Sat, May 30, 1998 at 05:40:52PM +0800, Bill Mitchell wrote:
> > I don't believe this is workable. First, I doubt that enough
> > developers would have the required system resources to work on 3 (or
> > more) different releases at the same time. Second, Debian has a
> > purely volunteer work force. It's hard enough already getting a
> > sustained effort working on a single release. If that effort was
> > diminished by dividing the volunteers across multiple releases,
> > nothing would ever get done.
>
> I don't think I succeeded in communicating my suggestion very well.
> I was speaking of just two releases above, debian-current (e.g., bo),
> and debian-next (e.g., hamm). The bo->hamm development model stabilized
Perhaps I did misunderstand part of your suggestion. I still stand by
my second though. Dividing the limited (vast as it is) work force
available to Debian is a bad thing.
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.
David
--
David Engel ODS Networks
david@sw.ods.com 1001 E. Arapaho Road
(972) 234-6400 Richardson, TX 75081
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: