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

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

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: