> On Wed, 28 Jun 2000, ^chewie wrote:
> > If there were ever to be a revolutionary change to how OS's are
> > installed and maintained, this would be it.  Coupling the ease of
> > use that 'apt' has given us with the quality control and
> > flexibility that the above scheme would allow us, we could pound
> > the market with job and quality specific installations of Debian
> > Linux.

On Wed, Jun 28, 2000 at 01:51:33PM -0500, Philip C Mendelsohn wrote:
> You brought up some good suggestions, but as Devil's Advocate, can I
> make the point that standards are wonderful things, but compliance
> is another matter entirely.  Making any version of any binary
> package available leaves compliance up to the given sysop, doesn't
> it?

In what context of compliance?  Compliance on the part of the person
installing the system.  You mean empowering the user to choose what is
best for a given situation or opinion?  Yeah, that'd be a bad thing,
wouldn't it. *grin*  

Or do you mean compliance on the part of the maintainers?  Ultimately
that lies within the body of the developers/maintainers.  We've got a
pretty faithful and enthusiastic crew supplying us with thousands of
packages.  How does policy change affect their enthusiasm or
committment?  These are rhetorical questions and can be debated as
long as you would like.  Instead, let's focus on the reality that any
organization whose developer selection process is as formalized as
Debian's, ultimately to ensure committment, would filter out those who
do not wish to comply.

> The real difference between the Debian distribution and any other is
> that they make compliance with a standard the default, and you can
> break away from it if you want.  The alternative, esposed by the
> other distros is "anything goes" and everyone gets to make up their
> own standards.

And how does my proposal operate against this?  I'm simply proposing
additional informational tags for identifying which meets standards
and which doesn't.  Releases or distributions are really based off
arbitrary decisions anyway.  My proposal just gives guidance and
trends from which to determine which packages to include in, let's
say, quarterly release mirrors.  Having a repository from which to
build releases is not a detriment, but an enhancement to the current
Debian policy and practice.

> I won't make judgements about which philosophy is more successful in
> the end -- that largely depends on what the purpose of the computer
> in question is.  I will say that I spend more time doing math or
> work on my system than surfing or gaming, so stability is more
> desirability to me than the age of any given component.

You're speaking of user/sysadmin choice rather than repository
configuration, flexibility, and quality control.

> My point is that quality control and flexibility *may* prove to be
> mutually exclusive.  Or more likely, opposite ends of a continuum.

If selection criteria or formulas compete against eachother, then you
make tradeoffs on the choices you settle upon.  You are referencing,
again, user or system administrator choice.  My proposal talks about
building an informational policy with which to TRACK and EVALUATE the
appropriateness of a given package or software, not whether or not
someone has the choice to use it or not.

Perhaps you're trying to say that when a user is bombarded with
information, dissemination of that info becomes too large of a chore
than its worth.  Great, rely upon others (like we do now) to make
arbitrary decisions on quarterly releases from which you leech
packages.  Rely upon tools such as apt to help you sift through
dependency and conflict issues.  Rely upon enhanced tools such as apt
to give you  information on package popularity (which is being used
today as a selection process for releases), package stability, and
software lifecycle.

I'm talking about information, categorization, and decision helpers,
not about making decisions for the users/systems administrators.

-- 
Chad "^chewie" Walstrom <chewie at wookimus.net>
        http://wookimus.net/chewie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 242 bytes
Desc: not available
Url : http://shadowknight.real-time.com/pipermail/tclug-list/attachments/20000628/a24b758b/attachment.pgp
-------------- next part --------------
---------------------------------------------------------------------
To unsubscribe, e-mail: tclug-list-unsubscribe at mn-linux.org
For additional commands, e-mail: tclug-list-help at mn-linux.org