From owner-freebsd-current  Sat Aug  2 13:59:16 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id NAA13810
          for current-outgoing; Sat, 2 Aug 1997 13:59:16 -0700 (PDT)
Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA13804
          for <current@FreeBSD.ORG>; Sat, 2 Aug 1997 13:59:13 -0700 (PDT)
Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.6/8.6.9) with ESMTP id NAA16221; Sat, 2 Aug 1997 13:58:14 -0700 (PDT)
To: ade@demon.net
cc: current@FreeBSD.ORG
Subject: Re: ports-current/packages-current discontinued 
In-reply-to: Your message of "Sat, 02 Aug 1997 21:53:35 BST."
             <E0wulBA-00008k-00@genghis.eng.demon.net> 
Date: Sat, 02 Aug 1997 13:58:14 -0700
Message-ID: <16217.870555494@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-freebsd-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> Well, given the major amount of work this is going to require in
> order to do things effectively, surely the first step is a
> mandate from the core team that a particular 'way forward' is
> the right way to go.  IMHO, 'leaving things as they are' isn't
> a valid option in this case, since we can see that things are
> starting to break down, as the system gets more complex.
> 
> Once the decision is made, then things can progress to discussion
> about how best to implement the decision, followed by resourcing
> the whole thing.
>
> Until the decision is made about the way forward, however, then
> much of the talk here is moot.

I think you're suffering from a fundamental misunderstanding of how
these things work. :-)

The core team can't really "mandate" anything without a much stronger
fait-accompli (e.g. the work essentially has to be ready to fold in
and the new mechanism approved in implementation as well as concept).
We've tried that before in the past, and all that's ever come of it is
an empty mandate - it doesn't serve as any kind of tie-breaker or
incentive for forward progress (you're probably thinking of a more
corporate model where once you have your "vision" you can go
essentially *order* your minions to go carry it out for you).

So it's really the other way around - until a truly defensible system
of package layering and installation is both proposed and proven
through some set of Makefile diffs which demonstrate the viability of
the concept, it's moot.

					Jordan