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

Re: so what? Re: Debian development modem



In article <[🔎] 19980531005520.A6485@elo> you wrote:

: You sort of suggested that the dividing line between core and non-core
: packages probably lies between the current optional and extra
: priorities.

Actually, I think everything through 'standard' is core, optional and extra
get lumped together pretty often in my mind. 

: 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?

Probably nothing.  I think the line between standard and optional, and the
line between optional and extra, have been pretty fuzzy.  In an era when it
all fit on one CD, it really didn't matter how things were prioritized.  If
we get to the point where thers is a difference in testing level, or the bits
are spread across units of distribution media, then these priorities will
become more clear... we'll care more about getting stuff in the right 
priorities... and users would pay more attention to package priority.  Yeah,
I know, that last is blue-sky... :-)

:> The second group is CD-focussed.

: This group hasn't historically been served well by Debian.

True.  I think this whole discussion of core and testing derives from that
fact, to some extent.

: That's an interesting approach.  I wonder how well the "stability
: implied by package age" approach would work out in real life.

I don't know.  The behavior that we realized we observe today is that people
in this category seem to wait for there to be a lull in the package upload
rate before they freshen the system.  Thus, we hypothesize that the "churn
rate" on packages might be a good first-order indicator of stability, if not
absolute quality.

It seems like an experiment or two with a tree built this way might be in 
order for slink.

: 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.

Amen, brother!  :-)

I do a lot of embedded systems work, and am painfully aware of libc funnies
there.  I'd really love it if my development platform's libc stabilized and
just didn't change in any meaningful way for a *long* time...

Bdale


--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: