> 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