Date: Tue, 5 Sep 2000 22:12:16 -0500 From: Steve Price <sprice@hiwaay.net> To: Will Andrews <will@physics.purdue.edu> Cc: FreeBSD Ports <ports@FreeBSD.ORG> Subject: Re: Ports Options Paper Message-ID: <20000905221216.A25531@bonsai.hiwaay.net> In-Reply-To: <20000903052226.E1205@radon.gryphonsoft.com>; from will@physics.purdue.edu on Sun, Sep 03, 2000 at 05:22:26AM -0500 References: <20000903052226.E1205@radon.gryphonsoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Sep 03, 2000 at 05:22:26AM -0500, Will Andrews wrote: # Hi all, # # This is the fruit of my brain's unused cycles, several nights of # sleepless thought, and several weeks of pondering. [proposal elided] Thank you Will for the proposal. You obviously spent a great deal of time thinking about this. Maybe I'm being a stick in the mud or maybe it is just too many years of formal training but I think we need to take a couple steps back and define what the Ports Collection is and derive a set of requirements for what we want it to become. Then we can design the system, code, test, code, test, ... ad infinitum. Sprinkle in a few redesigns, nix UML diagrams and use cases, and you almost have a formal design instead of the long series patches upon patches that we have today. Don't get me wrong I really like what we have today but there is always room for improvement. I also know many of you are saying that this is a volunteer project and you didn't come here to do formal designs and many of you including myself do this all day every day now. Please bear with me it doesn't need to be extremely formal. We just need to lay the groundwork before we jump in and code so we don't end up back in the same place as we are now a couple of years from now. Ok? So what is the Ports Collection? One definition could go something like this: The Ports Collection consists of two subsystems: the ports tree and a set of package management tools. The ports tree is responsible for building the packages used by the pkg_mgmt tools. The pkg_mgmt tools allow one to seemlessly (painlessly?) manage the installation/removal/upgrade of packages. Does this imply that nobody will use the ports tree except Satoshi and a few brave souls? Maybe. Depending on our goals (and their associated requirements) we might come up with a system where nobody every has to use anything but the pkg_mgmt tools unless they are expressly building packages. Is there a unique set of requirements for the ports tree and the the pkg_mgmt tools? Is there overlap and if so how do they interact? For instance, should the ports tree transparently handle upgrades, just the pkg_mgmt tools, or both? Does the ports tree have special requirements for the package format or just the pkg_mgmt tools? Maybe a good place to start would be to define the characteristics of the new Ports Collection and try to get at a set of requirements from there? What are the characteristics of the current system that need to be preserved, changed slightly, or completely overhauled? What are some things missing in the current system that are desired in the new system? A friend of mine from GE once told me about the SMART principle as it relates to requirements gathering - S?, Measurable, Attainable, R?, Testable. Remember before you blurt out that 'the ports tree shall use the minimum number of inodes' that this really isn't attainable. In my mind the minimum number of inodes is zero and I don't think we can construct a useful replacement for the Ports Collection that requires zero space. :) If you've made it this far... Thanks! I'll try to refrain from extended rants for awhile since after this I'm probably well above my quota. -steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000905221216.A25531>