Re: Releases means?
On Sun, 14 Jul 2002, Tortise@Paradise wrote: Hi I've been trying to sort out which update to download. I seek a stable version of FreeBSD. Am I correct that of the Current and Stable paths there are releases for each? ie that there are Current Releases and Stable Releases? I have downloaded releng_4_6 in the expectation it is the Stable Release. Clarity would be appreciated. With thanks in advance. David Hingston There is a current branch, and a stable branch, but those are not 'releases'. They're both moving targets which vary rapidly. every so often the stable branch is used to construct a new release. releng_4_6 gives you the latest (at present) stable release plus the critical fixes only. Andrew McNaughton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Releases
On Wed, Apr 11, 2001 at 06:20:18PM -0400, Dan Langille wrote: On 11 Apr 2001, at 22:51, Nik Clayton wrote: Done. Did I miss the commit? When was this done? 21:50 last night, to src/share/examples/cvsup/standard-supfile, on the RELENG_4 branch. ID 1.17.2.2. N -- FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- PGP signature
Re: Releases
oliver, On Wed, Apr 11, 2001 at 03:45:41PM +0200, Oliver Fromme wrote: Dan Langille [EMAIL PROTECTED] wrote: On 10 Apr 2001, at 14:48, David O'Brien wrote: On Tue, Apr 10, 2001 at 06:32:15AM +1200, Dan Langille wrote: AFAIK, the thread to date has been about whether or not [something like] the label "-development" would cause less confusion than "-current". My snipped for compactness Maybe it would reduce confusion somewhat if people would just stop saying ``4.1-stable'' etc. Those simply do not exist. I would also vote for ``uname -r'' saying ``4-STABLE'' and appending the date (similar to the snapshot naming), like ``4-STABLE-20010509''. This is much more useful than ``4.3-STABLE'', IMO. actually, given teh granularity of teh cvs system it might be worthwhile to add hh:mm .. on second thoughts your sugestion is teh sanest i've seen and personally wonder why it wasn't done like this fron teh begining. this is how cvs functions, and give we use cvs why not make it ease fro people to actually use the resources that are provide by cvs, i.e. the very system that we use. with regard and thanks. jonathan Just my 2 Euro cents ... and my two pacific peso centimes .. heading for 1 us cent and falling -- Jonathan Michaels http://www.caamora.com.au PO Box 144, Rosebery, NSW 1445suffering construction anxiety [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Releases
jonathan michaels [EMAIL PROTECTED] wrote: On Wed, Apr 11, 2001 at 03:45:41PM +0200, Oliver Fromme wrote: Maybe it would reduce confusion somewhat if people would just stop saying ``4.1-stable'' etc. Those simply do not exist. I would also vote for ``uname -r'' saying ``4-STABLE'' and appending the date (similar to the snapshot naming), like ``4-STABLE-20010509''. This is much more useful than ``4.3-STABLE'', IMO. actually, given teh granularity of teh cvs system it might be worthwhile to add hh:mm .. That would be rather difficult. As far as I know, there is no automatic mechanism to store the current date and time somewhere upon a cvs checkout or update. Anyway, just the day should be sufficient in most cases. Think of someone posting a well-known problem to -questions or -stable, and giving his uname output which says, for example, ``4-STABLE-20010509''. Now we can tell him to upgrade because it was fixed on 2001-05-20 or whatever. If he just said ``4.3-STABLE'', it wouldn't help much. Storing the date (without time of day) in that string would require some cron script somewhere (probably on the master CVS server) that updates the newvers.sh file daily. This might sound like a gross hack, but so far I haven't seen a better idea. on second thoughts your sugestion is teh sanest i've seen and personally wonder why it wasn't done like this fron teh begining. Probably because of the gross hack that I described above. :-) But maybe someone else has a better idea how to achieve that. Regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 Mnchen Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Releases
Maybe it would reduce confusion somewhat if people would just stop saying ``4.1-stable'' etc. Those simply do not exist. Best idea so far, and consequently change the bit in the handbook that implies that -STABLE is a bug fix to the last release, independent of the changes to making the next release. Tthats one of the major causes of confusions as it leads to people having an odd expectation of what the -STABLE actually is. -pete. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
RE: Releases
snipped a tad -Original Message- From: Oliver Fromme [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 11 April 2001 15:49 To: [EMAIL PROTECTED] Subject: Re: Releases I would also vote for ``uname -r'' saying ``4-STABLE'' and appending the date (similar to the snapshot naming), like ``4-STABLE-20010509''. This is much more useful than ``4.3-STABLE'', IMO. That would be rather difficult. Storing the date (without time of day) in that string would require some cron script somewhere (probably on the master CVS server) that updates the newvers.sh file daily. This might sound like a gross hack, but so far I haven't seen a better idea. Perhaps we could add something to either: i) snoop through the cvsup tags on the client to identify the most recently modified file and use it's datestamp as the '-stable-yymmdd' seed or ii) modify cvsup client to record most recently modified file in a more convenient place from which 'make buildworld' can retrieve the same, Michael Butler Managed Security Services Exodus Communications US Cell: +1-408-896-6689 Australian Cell: +61-413-571-819 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Releases
On Wed, Apr 11, 2001 at 09:48:57PM +0200, Oliver Fromme wrote: jonathan michaels [EMAIL PROTECTED] wrote: On Wed, Apr 11, 2001 at 03:45:41PM +0200, Oliver Fromme wrote: Maybe it would reduce confusion somewhat if people would just stop saying ``4.1-stable'' etc. Those simply do not exist. I would also vote for ``uname -r'' saying ``4-STABLE'' and appending the date (similar to the snapshot naming), like ``4-STABLE-20010509''. This is much more useful than ``4.3-STABLE'', IMO. actually, given teh granularity of teh cvs system it might be worthwhile to add hh:mm .. That would be rather difficult. As far as I know, there is no automatic mechanism to store the current date and time somewhere upon a cvs checkout or update. i wasn't sure, i am sort of fiddling with setting up some sort of source code management system (html, freebsd system sources, tcp/ip network maintenance et al) and i'm starting to get a handle on how cvs/rcs/perforce sort of work. Anyway, just the day should be sufficient in most cases. Think of someone posting a well-known problem to -questions or -stable, and giving his uname output which says, for example, ``4-STABLE-20010509''. Now we can tell him to upgrade because it was fixed on 2001-05-20 or whatever. yup, this is what i thought would be the best and given that i couldn't see how to get the granularity required to extract teh exactly required version and given that clocks are out and given that .. a whole lot of other things i endup with (as you rightly pointed out) settling on the date of the day of teh er, um whatever that part of teh 4-stable contium would be called. If he just said ``4.3-STABLE'', it wouldn't help much. yes, this has always been my problem since i started with freebsd back at 2.0.5-release, i could never reconcile who cvs and its mechanisms for getting and making on call 'images' so to speak of either a file, a subsystem or even teh whole of freebsd at a given point in time (usually a given day, being identified by its date). Storing the date (without time of day) in that string would require some cron script somewhere (probably on the master CVS server) that updates the newvers.sh file daily. This might sound like a gross hack, but so far I haven't seen a better idea. "gross hack", not advocating, most people have enough on thier plates already, i can see that getting what one needs from cvs for say releng_4 for say march 23rd 2001 ... then we all can call it freebsd 4-stable-23042001. instead of freebsd 4.?-stable as of sometime early this year and teh other time frame hack normally used. on second thoughts your sugestion is teh sanest i've seen and personally wonder why it wasn't done like this fron teh begining. Probably because of the gross hack that I described above. :-) maybe for teh hours:minutes part but for teh stable-23042001 that (from what i've managed to gather so far, ok) should be ok. just a bit of a discription reorganising because it is muchly what we are using right now, ummm i think. But maybe someone else has a better idea how to achieve that. given the tools we use, i think this sounds like teh most likely cource of action to take (from my perspective) but, ok, your probably right. with regards and thanks jonathan -- Jonathan Michaels http://www.caamora.com.au PO Box 144, Rosebery, NSW 1445suffering construction anxiety [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Why not stick with [STABLE] [Was: RE: Releases]
At 08:18 PM 4/9/01 -0700, Yann Sommer wrote: Heya all, I've been following this thread with some extra attention, since I remember beeing new to FreeBSD and complaining about a dedicated Server I ordered, running BETA. It is just, as has been mentioned a few times before on this list, against what other programms use for version naming. But, in my humble opinion I think the easiest solution has not been mentioned here before. Why not just suffix the old version description to stable, like: 4.3-STABLE-BETA 4.3-STABLE-RC 4.3-STABLE-FINAL The last is really 4.3-RELEASE or would it be 4.4-RELEASE, which opens up one more thing to confuse some. Mind I'm used to current naming. or something in that direction. The essential word "STABLE" which gives the newer users the trust in a system (allthough it's kind of stupid after knowing the exact naming, but heh, nobody gets born with all knowledge ;), and at the same time sticks with the naming BSD users are used to. Fact is what friggin difference does make what the build calls itself. Those that track the RELENG_4 branch should know that it doesn't matter what it calls itself when doing a uname, it is the same branch at different points or periods of time. The concept of how the naming is done is not an issue and cannot be solved by using a different or modified scheme. Rather the documentation should cover this. Just a matter of explaining what each period means in the handbook and/or/both the FAQ... When running -stable normally 'uname -r' will return a version such as 4.2-STABLE, which means the system is running code post 4.2-RELEASE. During the code freeze prior to the release of version 4.3 the name will change to 4.3-BETA, followed by 4.3-RC, and at a certain time a revision tag will be laid down and called 4.3-RELEASE. And a matter of minutes after that Jordan will change it over to 4.3-STABLE and the free-for-all will start anew. A chart might allow for a better visualization of the development cycle of a branch, noting the revision tags and what the system calls itself (found in src/sys/conf/newvers.sh for those that don't know). Would say cvsup.html is a good place for a quick note and somewhere else a chart explaining the development cycle that also show what the system will call itself at that point. Say an additional FAQ entry Then again if anyone perpetuating this thread had bothered to pay attention to the list (RYFM) and check out Nik's last message would know about: http://www.freebsd.org/FAQ/book.html#RELEASE-CANDIDATE and might find: http://www.freebsd.org/FAQ/book.html#STABLE Think that covers it... Don't forget to thank those working on the documentation for this solution and offer help if you are not happy with the way things are or praise if you are happy. There is a list for that hint-hint, so we need not do nothing more than point it out the next time this comes up and not bother to continue this discussion. Happy reading! Jeff Mountin - [EMAIL PROTECTED] Systems/Network Administrator FreeBSD - the power to serve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Releases
On Mon, Apr 09, 2001 at 03:54:32PM -0400, Matthew Emmerton wrote: Next, the case of the bind and ntpd updates. Yes, these were fixed in -STABLE and -CURRENT very quickly, but were only documented in UPDATING. How many people who are running -RELEASE have this? That's right, none. If the "current release" box had an "Newsflash" or other such link to inform users of 1) critical bugs that exist in the current release, and 2) HOWTOs that show how to fix them, then a lot of the confusion surrounding these fixes would be resolved. That's the "Errata" link. Suggestions for alternative text welcome. Note that the NTP bug hasn't had an advisory released yet (presumably because the security are busy working on it at the moment). Finally, almost every newbie I see asking a question asks "how can I do this on FreeBSD, and where is the HOWTO- to help me?" Most often these people are redirected to offsite repositories of information, rather than the documentation included with FreeBSD. IMHO, this contributes to the degradation of the existing documentation of FreeBSD, as more effort will go into updating third-party sources. Which sources. I am *very* interested in bringing more documentation in to the tree -- for example, I've been trying to get in touch with Dan who runs www.mostgraveconcern.com/freebsd/ to get them in to the tree, but so far, no response. Anyone that wants to submit documentation to the FreeBSD project is encouraged to do so. It's also a pretty fast track to becoming a committer. As ever, it's "rough consensus and working code" (or documentation, in this instance). Comments such as "The FAQ sucks" don't work. PRs that say "The FAQ sucks, because it doesn't answer this question, here's a patch ready to go" get looked at much more rapidly. N -- FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- PGP signature
Re: Releases
On Tue, Apr 10, 2001 at 05:29:43AM +1200, Dan Langille wrote: On Mon, 9 Apr 2001, Christopher Schulte wrote: At 03:45 AM 4/10/2001 +1200, Dan Langille wrote: Give meaningful and widely used names to things which people are familiar with. -CURRENT fits all those requirements. In this case, the familiarity is reduced to those familiar with the project. Witness the frequency with which the confusion arises. It's question five in the FAQ. http://www.freebsd.org/FAQ/preface.html#CURRENT The first para says "only of interest to developers working on the system and die-hard hobbyists". The second para says If you are not familiar with the operating system or are not capable of identifying the difference between a real problem and a temporary problem, you should not use FreeBSD-CURRENT. This branch sometimes evolves quite quickly and can be un-buildable for a number of days at a time. People that use FreeBSD-CURRENT are expected to be able to analyze any problems and only report them if they are deemed to be mistakes rather than ``glitches''. Questions such as ``make world produces some error about groups'' on the -CURRENT mailing list are sometimes treated with contempt. I don't see any way in which someone could start running -current without seeing that warning, or the equivalent warnings in the Handbook. Short of making -current refuse to build without a magic cookie in /etc/make.conf, and a webpage that contains that cookie along with this dire warning, I don't see how we can make it more obvious to people that they shouldn't be running -current if they don't know what they're doing. N -- FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- PGP signature
Re: Releases
On Mon, Apr 09, 2001 at 05:55:13PM -0500, Mike Meyer wrote: Jordan Hubbard [EMAIL PROTECTED] types: Just because the problem is difficult to solve does not mean it can not be or should not be solved. Fine, how about you solve it and the rest of us will get back to all the other stuff we have on our plates. :) I know, you're kidding. He's almost certainly not. FreeBSD is a huge time sink, and people work on whatever interests them. If this topic interests you then you're the best person to work on it, and submit changes. But if some group of people who have to deal with the questions propose a complete new naming scheme designed to deal with all the problems we see the current ones causing (though the only serious one is -BETA/-RC), is there any chance of it being adopted? There's certainly a chance. How about just a new name for either -BETA (the major source of the problem), or simply calling -STABLE -ALPHA, thus making -BETA -RC seem desirable? Because -STABLE is not alpha code, by any definition of "Alpha" that I'm familiar with. -STABLE is designed to be exactly that, "Stable code that is probably suitable to run your production systems on, with as few surprises as possible". N -- FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- PGP signature
Re: Releases
On Mon, Apr 09, 2001 at 01:38:15PM -0400, Michael R. Rudel wrote: x.x-BETA is ... notoriously buggy. It has bugs, that's the point of the x.y-GAMMA rather than x.y-BETA might would be a good move. Then we'd have 1/2 the world asking what "GAMMA" means. We could then hit over the head them with the cluebat and maybe it would stick. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
RE: Releases
:: Seems to me that if the lowest-common-denominator had some way to :: stay stable that didn't involve using cvsup or a compiler, this would :: be a non-issue. :: :: Numbered binary patches, anyone? Troll! ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Releases
At 03:45 AM 4/10/2001 +1200, Dan Langille wrote: Give meaningful and widely used names to things which people are familiar with. -CURRENT fits all those requirements. I'm not as hot about the BETA designation, but generally feel it should be left alone simply because it's documented, and thus should NOT be a problem. By this designation, we could call a brake a clutch and get away with it because it's all documented. The problem is not with the documentation. It's with the name. Documentation is not the only factor. The name was chosen for a *reason*, to convey a point. It's choice was not arbitrary. And it's since been accepted by the development and administrative community. Question being: Now, are we to a point where that accepted name needs to be reevaluated for the sake of general consensus, need or desire. That's the real question, IMHO. --chris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Releases
[... SNIP ...] Personally, I don't see a problem with the -CURRENT and -STABLE naming scheme. As someone said, anybody who can CVSup (not to mention get the sample CVSup files to work off of) yet not read the rest of the documentation has other issues. Renaming -CURRENT to -DEV or -DEVEL would be the equivlent of dulling all the knives in your house so that people don't cut themselves. As for -BETA, there isn't really a problem with this either, if you take it apart and look at it. From the Hacker's Dictionary, the definition of 'beta' is as follows: 1. Mostly working, but still under test; usu. used with `in': `in beta'. In the Real World, systems (hardware or software) software often go through two stages of release testing: Alpha (in-house) and Beta (out-house?). Beta releases are generally made to a group of lucky (or unlucky) trusted customers. 2. Anything that is new and experimental. "His girlfriend is in beta" means that he is still testing for compatibility and reserving judgment. 3. Flaky; dubious; suspect (since beta software is notoriously buggy). x.x-BETA is ... notoriously buggy. It has bugs, that's the point of the beta - to work the bugs out. If it didn't have bugs (that we knew about), it'd be -RELEASE. -STABLE is generally (with some execptions), more stable than -RELEASE, because it is a -RELEASE version with both ongoing bugfixes and (minor) new features. A release canidate is an almost ready release. Personally, I think these should be named GAMMA, DELTA, ... because that continues with the whole ALPHA or BETA trend. All these designitions do is indicate various stages of code freeze, and this is all documented places. Changing the whole release process of something that has worked for years isn't going to help anything, people are always going to be confused if you change it - if you suddenly change the way this shit is named, I'm going to be confused when 4.4 comes around or whatever. Just chill, and instruct people to Read The Fine Manual. -- Michael R. Rudel * 734.417.4859 * [EMAIL PROTECTED] AOL AIM: ATSTheory * Cell e-mail: [EMAIL PROTECTED] Network Engineer, Pinckney Community Schools Systems Engineer, NourDesign Corp Principal Engineer, Michael R. Rudel Consulting Authorized Representative, Charter Communications -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Releases
By this designation, we could call a brake a clutch and get away with it because it's all documented. The problem is not with the documentation. It's with the name. That's a nice pat answer, but the problem is that for every value of "name" we propose, somebody comes forward and says "But that confuses me." We can't call it BETA, we can't call it STABLE, we can't call it RC, we can't call it PRERELEASE, because each and every one of those have had push-back from people who said it would conflict with previous definitions they hold dear. Given that, chances are excellent that any other halfway logical names we come up with will suffer from the same problem. The real problem here is that we're trying to cater to the lowest common denominator, which is stupid people who leap before they look and then blame someone else for the injuries they sustain. It is for those very same people that legal liability forced McDonalds to write "Warning: This is called hot coffee. That means it is Hot. You should never, ever dump it into your crotch or on any other part of your body which is intended to remain unscalded. Did we mention that it's very hot?" If we were McDonalds (or Microsoft for that matter), we would also stop providing access to -stable and -current entirely because it had been statistically proven that the lower percentile out there was doing the equivalent of pouring coffee in their laps and we didn't want the liability. However, we're not them and I don't think we should try to twist ourselves into those kinds of shapes. Both -current and -stable are aimed at something other than "the masses" (for them, there are -releases in handy jewel-cased form) and are well documented as such in our handbook. The masses simply need to learn to stay out of those areas. To use another analogy, FreeBSD is not just a building, it's a building with a perpetual construction site next to it which is knocking up another building. As long as the office workers stay in their building, things are good. When they wander onto the construction site without hard-hats or an invitation for a guided tour, however, they should expect to get either squished or seriously yelled at and chased off the site by the first construction worker they run into. A construction site also generally has fences around it to stop the truly cerebrally challenged from crawling under the pile-driver, perhaps we need the same. I got it - unless you provide a special secret flag to it, cvsup always uses its GUI mode and presents the user with a disclaimer and release form which needs to be agreed to first. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Releases
On Mon, 9 Apr 2001, Christopher Schulte wrote: At 03:45 AM 4/10/2001 +1200, Dan Langille wrote: Give meaningful and widely used names to things which people are familiar with. -CURRENT fits all those requirements. In this case, the familiarity is reduced to those familiar with the project. Witness the frequency with which the confusion arises. I'm not as hot about the BETA designation, but generally feel it should be left alone simply because it's documented, and thus should NOT be a problem. By this designation, we could call a brake a clutch and get away with it because it's all documented. The problem is not with the documentation. It's with the name. Documentation is not the only factor. The name was chosen for a *reason*, to convey a point. It's choice was not arbitrary. Is this from experience or are you guessing? And it's since been accepted by the development and administrative community. The people already on the project understand. They have been "indoctrinated" for lack of a better term. It's the new people which have the trouble. Perhaps with a better name that trouble could be easily avoided. Question being: Now, are we to a point where that accepted name needs to be reevaluated for the sake of general consensus, need or desire. That's the real question, IMHO. I think so. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Releases
On Mon, Apr 09, 2001 at 10:26:50AM -0500, Christopher Schulte wrote: Change the designation just because some admins don't know how to RTFM? I don't think so... They fu*ked up. Plain and simple. -CURRENT makes sense, and more importantly is documented for those who take the time to look. With self-documenting labels documentation becomes unnecessary. Markus -- Markus Holmberg | Give me Unix or give me a typewriter. [EMAIL PROTECTED] | http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Releases
On Mon, 9 Apr 2001, Michael R. Rudel wrote: [... SNIP ...] Personally, I don't see a problem with the -CURRENT and -STABLE naming scheme. As someone said, anybody who can CVSup (not to mention get the sample CVSup files to work off of) yet not read the rest of the documentation has other issues. Renaming -CURRENT to -DEV or -DEVEL would be the equivlent of dulling all the knives in your house so that people don't cut themselves. A poor analogy. A better one would be labelling the knife drawer something other than knives. Changing the whole release process of something that has worked for years isn't going to help anything Nothing has been suggested about change the *process*. AFAIK, we're talking about the name. Not the process , people are always going to be confused if you change it - if you suddenly change the way this shit is named, I'm going to be confused when 4.4 comes around or whatever. Said confusion, if any, would be temporary and well announced. What is being proposed is a name which helps new people out and which will still make sense long after they've joined te project. Just chill, and instruct people to Read The Fine Manual. AFAIK, everyone is chilled. As for discarding the issue with a RTFM, that's avoiding the issue altogether and will not achieve anything. Reasoned discussion, whch is what I thought we were doing, will. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: supfile idea (was Re: Releases)
At 10:04 PM 4/9/01 -0400, Matthew Emmerton wrote: I like the idea of stable-supfile, so it should stay. standard-supfile should *definitely* refer to the -REL in which it is a part of. In that case, a novice user who doesn't change anything would end up cvsup'ing code that they already have on their system or on CD - no harm done. Further, they'd actually have to RTFM to figure out what tags to use to get what they really want. Another issue that is common here and wonder if you are aware of this file: /usr/src/share/examples/cvsup/README Frankly I think there should be the readme and *ONE* example. There is a lot of duplication and since most use only one cvsupfile, possibly less confusion. I see there is a disclaimer for adding the ports collection in the "standard" version. Use that as a base and these: ports-supfile stable-supfile standard-supfile www-supfile Can be rolled into one, call it "new-supfile" for now, and now there are only: README cvs-supfile gnats-supfile new-supfile refuse refuse.README Less choices and changing "new" to "standard" should make it the obvious choice and not require building up a typical supfile. Not sure that the gnats could be folded in, as it uses "release=current" rather than "release=cvs" and does not use a "tag=" and having one might throw it off (John? anyone?). Also might not be a good idea to fold it in, since only those that work on PR's might want a local copy. Another common issue is when using individual collection vs src-all. Many time a person has src-crypto and no src-secure. Or worse, someone points out only one of them is missing and neglects to mention the other. It would be difficult to say what is optional, but if you consider /etc/defaults/make.conf *and* lose the comments before the crypto collections (outdated, but might be necessary in the future) then something like: # required by default #src-base #src-bin #src-contrib #src-etc #src-games #src-gnu #src-include #src-lib #src-libexec #src-sbin #src-share #src-sys #src-usrbin #src-usrsbin #src-crypto #src-secure #src-sys-crypto # optional #src-kerberos5 #src-kerberosIV #src-release #src-tools #src-eBones And perhaps a quick reference to make.conf and a suggestion to pull in src-release even if one doesn't wish to roll their own for the text files that everyone tracking stable *should* know about. Perhaps a quick reference to the handbook or FAQ to avoid cluttering the file like this. # comment the following if "NOGAMES=yes" in make.conf #src-games # un-comment the following if "MAKE_KERBEROS5=yes" in make.conf etc... The idea is to make it simple, central, and with simple comments that should avoid the common mistakes. And yes, I am aware that removing the supfiles for ports, doc, www, and stable would require a change to make.conf. They could remain and the standard might be updated to an all-in-one supfile rather than for -current. Perhaps all that is needed is a comment in the README to refer to the handbook for those new to fetching the source and what should be used when using individual collections. Minimal clutter and hopefully get more to RTFM before diving in. Mind right now I'm not sure where the docs are and how satisfactory they are (no insult to the docs people). Was going to update them, but find the docproj has bloated quite a bit in recent history. Might want to warn those fetching doc-all what it will take to build that beast. 8-) Can Kris or someone else say if src-sys-crypto is required or not. There was a discussion on this a long time back, but recall the answer was fuzzy and it *might* be required in the future for in-kernel crypto. I do list it when suggesting a trimmed down list rather than src-all. It's small and safer to do so. Rather than reply to another will agree with Donn that "standard" should be "current" to avoid confusion. Then making "standard" an all inclusive (or should I say "mostly") example might be a good idea along with pointing to documentation. Of course getting users to read things is always an issue. All the documentation in the world won't stop a (l)user from getting a bad case of LLMF. My question at this point is before changing a thing it would be best to find out how most get lost and then work out a remedy, which I could have stated in the first place and had less fun trying to cover a number of possibilities. duck It would be nice to force a new user to a certain minimum of RTFM, but might leave some cold and certainly won't stop them from not doing so, screwing up, and asking "why?" Attaching a copy of my idea of what standard-supfile should be like. standard-supfile-new Jeff Mountin - [EMAIL PROTECTED] Systems/Network Administrator FreeBSD - the power to serve
