Re: Difference between RELENG_* and RELENG_*_BP
On Mon, May 13, 2002 at 12:49:44PM -0700, Terry Lambert wrote: > void wrote: > > > A: ``I'll give you $200 to add $foo to the base system.'' > > > B: ``No, *I* bid $300 to get someone to work on $bar.'' > > > ... > > > > This has been mooted before, and I think people have even made efforts > > to implement, but it's never taken off in a big way. > > Or Alfred would be driving a BMW. 8-). Can I have the Audi S8 with W12 engine please? :-P -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Difference between RELENG_* and RELENG_*_BP
void wrote: > > A: ``I'll give you $200 to add $foo to the base system.'' > > B: ``No, *I* bid $300 to get someone to work on $bar.'' > > ... > > This has been mooted before, and I think people have even made efforts > to implement, but it's never taken off in a big way. Or Alfred would be driving a BMW. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Difference between RELENG_* and RELENG_*_BP
On Sat, May 11, 2002 at 01:23:33AM -0700, David Schultz wrote: > > I think you're on to something here. Just imagine: > > A: ``I'll give you $200 to add $foo to the base system.'' > B: ``No, *I* bid $300 to get someone to work on $bar.'' > ... This has been mooted before, and I think people have even made efforts to implement, but it's never taken off in a big way. I have seen several people offer USD100 to the first person to fix a particular bug. The claimer of the bounty usually asks that it be contributed to the FreeBSD Foundation, which is nice. -- Ben "An art scene of delight I created this to be ..." -- Sun Ra To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Difference between RELENG_* and RELENG_*_BP
Thus spake Terry Lambert <[EMAIL PROTECTED]>: ... > Doesn't bugzilla still have that remote exploit problem that > was reported on Bugtraq? > > Also, I think voting is generally done by "write the code". > You really can't demand volunteers work on what you want them > to work on. I think you're on to something here. Just imagine: A: ``I'll give you $200 to add $foo to the base system.'' B: ``No, *I* bid $300 to get someone to work on $bar.'' ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Difference between RELENG_* and RELENG_*_BP
David Schultz wrote: > Thus spake Brandon D. Valentine <[EMAIL PROTECTED]>: > > I know we've got gnats, but gnats doesn't really provide any of the > > Request for Enhancement/voting features that Bugzilla does. FreeBSD > > seems to have grown to a point where maybe some of Bugzilla's workflow > > benefits could be realized. The ability for developers and users to > > vote for or against a specific feature certainly wouldn't hurt. > > I don't know about that; the current system seems to work pretty well. > Best of all, things actually get done without there being religious > wars about the colors of various bikesheds. When an issue comes up > that people *really* care about, it finds its way to the lists anyway. > If people had to vote about every little change, I imagine there'd be > chaos. Voting isn't the right way to settle a disagreement anyway. Doesn't bugzilla still have that remote exploit problem that was reported on Bugtraq? Also, I think voting is generally done by "write the code". You really can't demand volunteers work on what you want them to work on. If someone asks for comments, feel free to comment, and if they start a public discussion, feel free to discuss, but I think "voting on bug fixes" has the ring of imposing management on people who you are not paying enough to put up with it. It worked for Mozilla because Netscape paid people to put up with doing work they didn't want to do and getting input from people who were unwilling to write the code themselves. Pure volunteer efforts are different. To persuade, you can't just vote, you actually have to be persuasive. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Difference between RELENG_* and RELENG_*_BP
Thus spake Brandon D. Valentine <[EMAIL PROTECTED]>: > I know we've got gnats, but gnats doesn't really provide any of the > Request for Enhancement/voting features that Bugzilla does. FreeBSD > seems to have grown to a point where maybe some of Bugzilla's workflow > benefits could be realized. The ability for developers and users to > vote for or against a specific feature certainly wouldn't hurt. I don't know about that; the current system seems to work pretty well. Best of all, things actually get done without there being religious wars about the colors of various bikesheds. When an issue comes up that people *really* care about, it finds its way to the lists anyway. If people had to vote about every little change, I imagine there'd be chaos. Voting isn't the right way to settle a disagreement anyway. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Difference between RELENG_* and RELENG_*_BP
On Fri, 3 May 2002, Leo Bicknell wrote: >At the end of the day, we need to lower the barrier to adding >documentation, while increasing the quality. Far from an easy task. I agree with your point. It would be nice to break down barriers to documentation. However, I don't think any of the suggestions so far are feasible, for reasons others have already point out. Moderated comment systems are very prone to low signal to noise ratios. They simply make it /too/ easy for any passerby to add something. This often leads to a lack of forethought on the part of the submitter. You end up with lots of poorly formatted, poorly worded hints that might, maybe help someone to get started solving their problem. This obviously doesn't help much. As for Wiki's, they're strictly the playground of crank 'computer science' theorist whack jobs. The only people who post to Wiki's are those who setup and maintain Wiki's. Show me a Wiki which has made a valuable contribution to the trust of human knowledge and I'll show you Armageddon. Maybe there is a way to break down a few barriers to creating better documentation and to simplify code contributions sans commit privs. Has anyone seriously looked into setting up a Bugzilla database for FreeBSD? I know we've got gnats, but gnats doesn't really provide any of the Request for Enhancement/voting features that Bugzilla does. FreeBSD seems to have grown to a point where maybe some of Bugzilla's workflow benefits could be realized. The ability for developers and users to vote for or against a specific feature certainly wouldn't hurt. The Bugzilla database could very easily contain a docs category where users could post documentation submissions. Other users looking for something not already in the handbook or FAQ could then be directed to check the bugzilla database for submissions. There's even the possibility of a special interface to the handbook which below each section links to bugzilla entries associated with that section. Users who click through and find a documentation submission helpful could then add their vote to it so that it gets pushed up high enough that people in the documentation project see it, are aware that users out there are finding it useful, and set about incorporating it into the official documentation. Brandon D. Valentine -- "Time to resign from the human race, wipe those tears from your lovely face. Baby, wave to the man in the ol' red caboose before all hell breaks loose." - Kinky Friedman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Difference between RELENG_* and RELENG_*_BP
In a message written on Fri, May 03, 2002 at 11:15:58AM -0700, JJ Behrens wrote: > The online documentation for PHP allows users to post comments at the end of > every page of the online documentation. Often times, these comments serve to > enlighten others about various quirks of the libraries. Perhaps doing the same > thing with the FreeBSD handbook pages (only online) might be a good idea. Allowing random comments (alone) isn't useful. More often than not PHP comments are not useful, or outright wrong. That said, we need to break down the barriers to good documentation. I think we could learn something from slashdot.org here, in that the right solution might be not only to have comments, but also to have moderators. In this way the user community can not only submit comments, but also rank them so we separate the wheat from the chaff. In the case of documentation it would also be essential to remove highly moderated comments as they are integrated into the documentation. At the end of the day, we need to lower the barrier to adding documentation, while increasing the quality. Far from an easy task. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Difference between RELENG_* and RELENG_*_BP
On Fri, May 03, 2002 at 11:15:58AM -0700, JJ Behrens wrote: > > The online documentation for PHP allows users to post comments at the end of > every page of the online documentation. Often times, these comments serve to > enlighten others about various quirks of the libraries. Perhaps doing the same > thing with the FreeBSD handbook pages (only online) might be a good idea. > > To critique myself, in this particular situation, the handbook details the that > -STABLE isn't stable very well in section 19.2.2 (I'm always impressed by how > nice the handbook is). However, user comments at the end might be nice to > explain why this branch has historically been called stable, and why it'd be > too difficult to change the name. > > If there's a general concensus that this would be a good idea, I'd be willing > to help make it happen. That would help a lot. From the point of view of a native English speaker, the nomenclature is certainly confusing. Explaining why it is so is OK, pointing out that it is not to be taken literally will help. What I would like is a few explicit examples (HowTOs ) ... for instance, I have installed from the 4.5 CD rom set. If all I want is security fixes, what tag do I put in my cvsup file? Or don't I do that at all? So, starting from a CD installation: 1. What is the procedure (is there a procedure?) for only getting security fixes? 2. Is there a procedure for only getting serious bug fixes? Are 1 and 2 above mutually exclusive? While I greatly appreciate the effort that goes into both the code and the documentation, this STABLE/CURRENT/who-knows-what-to-fix-security stuff gives the Unix bashers yet another opportunity to badmouth the effort. If I could get clear on 1 and 2 above, I wouldn't care at all if the terms used were GOLD/SILVER/PLATINUM/DROSS/LEAD/FLUFFY/SQUOOSHY. Thank you -=[Lou Katz]=- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Difference between RELENG_* and RELENG_*_BP
> All this dovetails with something I expressed earlier, with regards to > annotating documentation. Somehow, this community needs to be able to > process a certan class of ideas in a format other than linear mailing > lists. Perhaps some sort of meta-document is needed which describes > how things currently work, and some sort of attachable discussion > needs to go with ideas in that document. Perhaps this is the handbook? > > I don't have a completely clear picture yet. Maybe some of you can > help me get one? =) The online documentation for PHP allows users to post comments at the end of every page of the online documentation. Often times, these comments serve to enlighten others about various quirks of the libraries. Perhaps doing the same thing with the FreeBSD handbook pages (only online) might be a good idea. To critique myself, in this particular situation, the handbook details the that -STABLE isn't stable very well in section 19.2.2 (I'm always impressed by how nice the handbook is). However, user comments at the end might be nice to explain why this branch has historically been called stable, and why it'd be too difficult to change the name. If there's a general concensus that this would be a good idea, I'd be willing to help make it happen. -jj -- Users of C++ should consider hanging themselves rather than shooting their legs off--it's best not to use C++ simply as a better C. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Difference between RELENG_* and RELENG_*_BP
On Fri, 3 May 2002 09:15:01 -0400 Brian T.Schellenberger <[EMAIL PROTECTED]> wrote: BTS> Stable is, in fact, fairly stable. I mean, if you are going to track updates I would go so far as to say that -stable is remarkably stable. So much so that it is easily mistaken for some kind of magicly tested prerelease track. The fact that this mistake can be made is an impressive tribute to the committers involved, the fact that it can be made so often is even more impressive. The most effective way to reduce expectations on the branch would probably be to break it more often - I am quite happy with this not being tried :) -- C:>WIN | Directable Mirrors The computer obeys and wins.|A Better Way To Focus The Sun You lose and Bill collects. | licenses available - see: | http://www.sohara.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Difference between RELENG_* and RELENG_*_BP
Brian T.Schellenberger wrote: > The existance of this thread merely demonstrates that people don't make use > the resources that are already out there. No, the existence of this thread demonstrates that the historical explanation is less than satisfying as an excuse for the broken nomenclature -- and that's why it keeps coming up. I realize that it's SOP some places to fix bugs by documenting them, but was hoping for something better here ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Difference between RELENG_* and RELENG_*_BP
On Friday 03 May 2002 02:37 am, Dave Hayes wrote: | | | All this dovetails with something I expressed earlier, with regards to | annotating documentation. Somehow, this community needs to be able to | process a certan class of ideas in a format other than linear mailing | lists. Perhaps some sort of meta-document is needed which describes | how things currently work, and some sort of attachable discussion | needs to go with ideas in that document. Perhaps this is the handbook? It seems to me that the community already has something like this. It is called the handbook, and it explains what "stable" is in FreeBSD (the stable *development* branch) quite clearly. The existance of this thread merely demonstrates that people don't make use the resources that are already out there. Other than by replacing the human race with somne other sort of audience, though, I don't see how we can do anything about *that*. Stable is, in fact, fairly stable. I mean, if you are going to track updates in a day-by-day basis, you can scarcely expect perfect stability anyway; if you want perfect stability, you go with releases and apply security patches. -- Brian T. Schellenberger . . . . . . . [EMAIL PROTECTED] (work) Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal) http://www.babbleon.org http://www.eff.org http://www.programming-freedom.org If you smell the smoke you don't need to be told what you've got to do; Yet there's a certain breed, so very in-between, they'd rather take a vote. -- DEVO -- Here To Go To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Difference between RELENG_* and RELENG_*_BP
Brooks Davis <[EMAIL PROTECTED]> writes: > DO NOT EVEN CONSIDER STARTING THIS THREAD!!! It's been hashed Double gah. Forget I said anything. ;) > However, just ranting about this problem[0] won't accomplish anything > other then wasting a lot of time and energy, IMO. There's plenty of > historic evidence to support this view in the archives. If you want > change you'll have to try another one. These kinds of threads are indicative of a meta-problem. The loop goes like this: 1) Someone new brings up a "flame...er hashed over" problem again, usually because it really is a problem. 2) People jump on the person (inadvertently hard perhaps) who brings it up. 3) The person goes to the archives to find this discussion and can't do it due to the inadequecies of the mailing list search and browse features 4) Said person goes away frustrated 5) Go to 1 Meanwhile the original problem never gets solved nor even (useful) mindshare thrown at it. Am I flaming about this? No. Do I want some way to solve these (and other) problems without irritating everyone who's already fla...er discussed this before? YES, and there needs to be a faster way to get up to speed with these legacy discussions. A couple examples off the top of my head of these kinds of discussions are: * naming of -stable * why Xfree86 v4 wasn't in FreeBSD (until now) All this dovetails with something I expressed earlier, with regards to annotating documentation. Somehow, this community needs to be able to process a certan class of ideas in a format other than linear mailing lists. Perhaps some sort of meta-document is needed which describes how things currently work, and some sort of attachable discussion needs to go with ideas in that document. Perhaps this is the handbook? I don't have a completely clear picture yet. Maybe some of you can help me get one? =) -- Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] >>> The opinions expressed above are entirely my own <<< A sample is a sample. Yet nobody would buy my house when I showed them a brick from it. - Mulla Nasrudin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Difference between RELENG_* and RELENG_*_BP
On Thu, May 02, 2002 at 10:03:24PM -0700, Michael Sierchio wrote: > Brooks Davis wrote: > > >>I'm sure you folks hashed this all over before, but really...calling a > >>branch "-stable" when it really isn't is not good semantic practice > >>IMNSHO. > > > > > > DO NOT EVEN CONSIDER STARTING THIS THREAD!!! It's been hashed over more > > times then are worth counting on various mailing lists which are fully > > archived. If you really care go read the flamewars there, don't start > > them on the list. The signal to noise ratio is bad enough without this > > junk. > > That's right, let's not make any mention of the pink hippo in the living > room. The nomenclature is fup duck. It should be changed. Just > because there's a historical explanation for abusing the language > doesn't mean it should be perpetuated. Sorry, shouldn't have flamed like that. :( However, just ranting about this problem[0] won't accomplish anything other then wasting a lot of time and energy, IMO. There's plenty of historic evidence to support this view in the archives. If you want change you'll have to try another one. If someone has a solid proposal that addresses the various problems, they should talk to [EMAIL PROTECTED] who actually makes this sort of decision and try to get some agreement. If they do agree, great. If not, flamewars -stable won't change that. -- Brooks [0] I'll agree it is one, but I don't think it's worth the pain and confusion solving it would require. Obviously others disagree. -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg34063/pgp0.pgp Description: PGP signature
Re: Difference between RELENG_* and RELENG_*_BP
Brooks Davis wrote: >>I'm sure you folks hashed this all over before, but really...calling a >>branch "-stable" when it really isn't is not good semantic practice >>IMNSHO. > > > DO NOT EVEN CONSIDER STARTING THIS THREAD!!! It's been hashed over more > times then are worth counting on various mailing lists which are fully > archived. If you really care go read the flamewars there, don't start > them on the list. The signal to noise ratio is bad enough without this > junk. That's right, let's not make any mention of the pink hippo in the living room. The nomenclature is fup duck. It should be changed. Just because there's a historical explanation for abusing the language doesn't mean it should be perpetuated. Bad semantics could definitely be considered noise. -STABLE is unstable (or potentially so). -SECURITY (which isn't really a tag) is what most people think of when they lex the term "stable." Squelching the insightful newcomer is the sign of disease. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Difference between RELENG_* and RELENG_*_BP
On Thu, May 02, 2002 at 08:44:02PM -0700, Dave Hayes wrote: > Terry Lambert <[EMAIL PROTECTED]> writes: > > -STABLE is called -STABLE these days, but RELENG_X -STABLE is > > really RELENG_X_Y + changes pending RELENG_X_(Y+1). Way back > > when, I think we had a long knock-down drag-out fight about > > naming of -STABLE vs. -DEVEL, and the expectations users have > > about the resulting code. That was where -SECURITY showed up: > > -SECURITY is a "stable version of -STABLE" (as if things weren't > > exciting enough... 8-) 8-)). > > Gah! Too much excitement for me. ;) > > I'm sure you folks hashed this all over before, but really...calling a > branch "-stable" when it really isn't is not good semantic practice > IMNSHO. DO NOT EVEN CONSIDER STARTING THIS THREAD!!! It's been hashed over more times then are worth counting on various mailing lists which are fully archived. If you really care go read the flamewars there, don't start them on the list. The signal to noise ratio is bad enough without this junk. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg34061/pgp0.pgp Description: PGP signature
Re: Difference between RELENG_* and RELENG_*_BP
Thanks all for the responses. Between the web pages and this discussion, my knowledge of this has now become a *lot* clearer. Terry Lambert <[EMAIL PROTECTED]> writes: > -STABLE is called -STABLE these days, but RELENG_X -STABLE is > really RELENG_X_Y + changes pending RELENG_X_(Y+1). Way back > when, I think we had a long knock-down drag-out fight about > naming of -STABLE vs. -DEVEL, and the expectations users have > about the resulting code. That was where -SECURITY showed up: > -SECURITY is a "stable version of -STABLE" (as if things weren't > exciting enough... 8-) 8-)). Gah! Too much excitement for me. ;) I'm sure you folks hashed this all over before, but really...calling a branch "-stable" when it really isn't is not good semantic practice IMNSHO. -- Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] >>> The opinions expressed above are entirely my own <<< "All the wonders you seek are within yourself." -Sir Thomas Brown To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Difference between RELENG_* and RELENG_*_BP
Drew Tomlinson wrote: > Yes it does. Thank you for your through and detailed explaination. I'm positive that someone else could have done a better job, and then updated the documentation (hint hint 8-)). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Difference between RELENG_* and RELENG_*_BP
- Original Message - From: "Terry Lambert" <[EMAIL PROTECTED]> Sent: Thursday, May 02, 2002 3:37 PM > Drew Tomlinson wrote: > > I'm just trying to understand. :) How is RELENG_X_Y_BP different from > > RELENG_X_Y_RELEASE? > > For the most part, studying the FreeBSD source tree is a good lesson > in how to be clever in your use of CVS. The only place it really > falls down is in the lack of vendor tagging for things lice sendmail, > etc., which really want to be brought in on a vendor branch, and then > branch tagged then rtagged, so that local modifications can be done > without screwing with the ability to bring a new release of the code > in on the vendor branch, and then re-tag and re-merge it. > > Archie Cobbs and Julian and Bryan Mann worked out a pretty good > system, which we used at Whistle, and then for those things that > didn't fit, I "rewrote history" by re-checking them in and retagging > them. > > Archie wrote a little FAQ on that; I don't know if he'd be willing > to share it. > > But to use the same approach for, for example, sendmail in FreeBSD, > would require some Makefile changes, some .mk file changes, and a > seperate parallel "module" branch (the main branch would check out > from the module branch *with a particular tag* as part of the build > process, and then descend into the checked out code). It's not > impossible to build without a CVS tree if you do that, but it makes > it harder, so it's probably not an acceptable approach for FreeBSD > to use directly. > > But to answer directly the question: > > RELENG_X_Y_RELEASE marks "end of work" > > RELENG_X_Y_BP marks "start of work". > > If you look at the diagram on the referenced web page, you end up > with two different branch heads. > > -- > > Like I said, you need a third dimension, or an angled line (pseudo > Z axis) to represent it in a two dimensional diagram. I'll use > indentation (below) to represent an X/Z diagram off the RELENG_4 > point in the X/Y diagram. > > If it weren't for the need to rtag it to get the -SECURITY branch > head, the _BP version would probably not have been done with an > rtag, and would use a simple tag, instead. > > Look at the example in the middle. It's confusing, because you > would expect the tag ordering to be: > > RELENG_4 > RELENG_4_4 <---.--- could use "tag" > RELENG_4_4_BP <---' > RELENG_4_4_RELEASE > > because you would expect that, as time goes on, you would tack > more and more suffixes onto the thing. But the actual ordering is: > > RELENG_4 > RELENG_4_4_BP <---.--- needs "rtag" > RELENG_4_4 <---' > RELENG_4_4_RELEASE <--- From -STABLE, not -SECURITY > > Make sense now? Yes it does. Thank you for your through and detailed explaination. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Difference between RELENG_* and RELENG_*_BP
Brooks Davis wrote: > On Thu, May 02, 2002 at 03:15:53PM -0700, Drew Tomlinson wrote: > > I'm just trying to understand. :) How is RELENG_X_Y_BP different from > > RELENG_X_Y_RELEASE? > > RELENG_X_Y_BP is the point on RELENG_X where the RELENG_X_Y branch was > created. RELENG_X_Y_0_RELEASE is the point on the RELENG_X_Y branch > which corresponds to what ends up in the actual release. It generally > has a few changes relative to the branch point point, but not too many. > RELENG_X_Y_BP is mostly an artifact of the way CVS works and is of little > if any real intrest. There certaintly isn't any real point in checking > it out. Exactly. It's there to branch, and to provide something so you can "cvs diff -r RELENG_X_Y_BP" a checked out tree to get patches to move them between parallel heads (-STABLE vs. -SECURITY) that supposedly contain "some of the same code" and "more of the same code", both "relative to the same branch point". -STABLE is called -STABLE these days, but RELENG_X -STABLE is really RELENG_X_Y + changes pending RELENG_X_(Y+1). Way back when, I think we had a long knock-down drag-out fight about naming of -STABLE vs. -DEVEL, and the expectations users have about the resulting code. That was where -SECURITY showed up: -SECURITY is a "stable version of -STABLE" (as if things weren't exciting enough... 8-) 8-)). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Difference between RELENG_* and RELENG_*_BP
Drew Tomlinson wrote: > I'm just trying to understand. :) How is RELENG_X_Y_BP different from > RELENG_X_Y_RELEASE? For the most part, studying the FreeBSD source tree is a good lesson in how to be clever in your use of CVS. The only place it really falls down is in the lack of vendor tagging for things lice sendmail, etc., which really want to be brought in on a vendor branch, and then branch tagged then rtagged, so that local modifications can be done without screwing with the ability to bring a new release of the code in on the vendor branch, and then re-tag and re-merge it. Archie Cobbs and Julian and Bryan Mann worked out a pretty good system, which we used at Whistle, and then for those things that didn't fit, I "rewrote history" by re-checking them in and retagging them. Archie wrote a little FAQ on that; I don't know if he'd be willing to share it. But to use the same approach for, for example, sendmail in FreeBSD, would require some Makefile changes, some .mk file changes, and a seperate parallel "module" branch (the main branch would check out from the module branch *with a particular tag* as part of the build process, and then descend into the checked out code). It's not impossible to build without a CVS tree if you do that, but it makes it harder, so it's probably not an acceptable approach for FreeBSD to use directly. But to answer directly the question: RELENG_X_Y_RELEASE marks "end of work" RELENG_X_Y_BP marks "start of work". If you look at the diagram on the referenced web page, you end up with two different branch heads. -- Like I said, you need a third dimension, or an angled line (pseudo Z axis) to represent it in a two dimensional diagram. I'll use indentation (below) to represent an X/Z diagram off the RELENG_4 point in the X/Y diagram. If it weren't for the need to rtag it to get the -SECURITY branch head, the _BP version would probably not have been done with an rtag, and would use a simple tag, instead. Look at the example in the middle. It's confusing, because you would expect the tag ordering to be: RELENG_4 RELENG_4_4 <---.--- could use "tag" RELENG_4_4_BP <---' RELENG_4_4_RELEASE because you would expect that, as time goes on, you would tack more and more suffixes onto the thing. But the actual ordering is: RELENG_4 RELENG_4_4_BP <---.--- needs "rtag" RELENG_4_4 <---' RELENG_4_4_RELEASE <--- From -STABLE, not -SECURITY Make sense now? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Difference between RELENG_* and RELENG_*_BP
On Thu, May 02, 2002 at 03:15:53PM -0700, Drew Tomlinson wrote: > I'm just trying to understand. :) How is RELENG_X_Y_BP different from > RELENG_X_Y_RELEASE? RELENG_X_Y_BP is the point on RELENG_X where the RELENG_X_Y branch was created. RELENG_X_Y_0_RELEASE is the point on the RELENG_X_Y branch which corresponds to what ends up in the actual release. It generally has a few changes relative to the branch point point, but not too many. RELENG_X_Y_BP is mostly an artifact of the way CVS works and is of little if any real intrest. There certaintly isn't any real point in checking it out. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg34055/pgp0.pgp Description: PGP signature
Re: Difference between RELENG_* and RELENG_*_BP
If memory serves me right, Terry Lambert wrote: > "Bruce A. Mah" wrote: > > > either for a code slush, > > > or for other work that may not make it back in until it's > > > complete, which might take a while. > > > > Nope. The original poster asked about RELENG_* branches; they aren't > > used that way, which I'm sure you know. > > ??? What I'm saying is that we almost never put something on a RELENG_* branch until it "make[s] it back in" to HEAD. Instead, changes get merged *from* HEAD *to* a RELENG_4 branch. Your original text gave what I thought was an erroneous impression. > I guess it's not obvious, since FreeBSD refers to things in > general a little differently: > > -- --- > The tag What people commonly call it > -- --- > RELENG_X-STABLE (X.x branch) > RELENG_X_Y_RELEASE -RELEASE (version X.Y) > RELENG_X_Y -SECURITY (X.Y branch) > RELENG_X_Y_BP RELENG_X at the time RELENG_X_Y was created > -- --- We don't have RELENG_X_Y_RELEASE tags, they're really RELENG_X_Y_0_RELEASE. But that's a bit of a nitpick. You're essentially right. > -STABLE is "other work that may not make it back in until > it's complete" relative to -SECURITY, and RELENG_(X+1) in > progress the same, relative to -STABLE (but you have an > implied tag that doesn't exist until it's "complete"). ENOPARSE > > Anyone wanting more information about how we *really* use the RELENG_* > > branches should take a read through Murray Stokely's release > > engineering article: > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/index.html > > Yes; this is a very good document. Unfortunately, it doesn't > provide a translation from RELENG-speak into mailing list speak; > the diagram doesn't really show a derivation relationship quite > correctly. Really, you need a tird dimention, or an angled line > in the diagram to get it right (particularly X.Y-STABLE). He did > a much better one on the whiteboard. Satoshi does a pretty good > one on a whiteboard, too; so does Julian. 8-). Yeah. Been too long since I used pic though...I wonder where my Tenth Edition UNIX manuals went to... Bruce. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Difference between RELENG_* and RELENG_*_BP
- Original Message - From: "Terry Lambert" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Dave Hayes" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, May 02, 2002 3:02 PM Subject: Re: Difference between RELENG_* and RELENG_*_BP [snip] > I guess it's not obvious, since FreeBSD refers to things in > general a little differently: > > -- --- > The tag What people commonly call it > -- --- > RELENG_X -STABLE (X.x branch) > RELENG_X_Y_RELEASE -RELEASE (version X.Y) > RELENG_X_Y -SECURITY (X.Y branch) > RELENG_X_Y_BP RELENG_X at the time RELENG_X_Y was created > -- --- I'm just trying to understand. :) How is RELENG_X_Y_BP different from RELENG_X_Y_RELEASE? Thanks, Drew [snip] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Difference between RELENG_* and RELENG_*_BP
"Bruce A. Mah" wrote: > > either for a code slush, > > or for other work that may not make it back in until it's > > complete, which might take a while. > > Nope. The original poster asked about RELENG_* branches; they aren't > used that way, which I'm sure you know. ??? http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/release-proc.html "The next step is to create a branch point tag, so that diffs against the start of the branch are easier with CVS: /usr/src# cvs rtag -rRELENG_4 RELENG_4_4_BP src And then a new branch tag is created with: /usr/src# cvs rtag -b -rRELENG_4_4_BP RELENG_4_4 src I guess it's not obvious, since FreeBSD refers to things in general a little differently: -- --- The tag What people commonly call it -- --- RELENG_X-STABLE (X.x branch) RELENG_X_Y_RELEASE -RELEASE (version X.Y) RELENG_X_Y -SECURITY (X.Y branch) RELENG_X_Y_BP RELENG_X at the time RELENG_X_Y was created -- --- -STABLE is "other work that may not make it back in until it's complete" relative to -SECURITY, and RELENG_(X+1) in progress the same, relative to -STABLE (but you have an implied tag that doesn't exist until it's "complete"). > Anyone wanting more information about how we *really* use the RELENG_* > branches should take a read through Murray Stokely's release > engineering article: > > http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/index.html Yes; this is a very good document. Unfortunately, it doesn't provide a translation from RELENG-speak into mailing list speak; the diagram doesn't really show a derivation relationship quite correctly. Really, you need a tird dimention, or an angled line in the diagram to get it right (particularly X.Y-STABLE). He did a much better one on the whiteboard. Satoshi does a pretty good one on a whiteboard, too; so does Julian. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Difference between RELENG_* and RELENG_*_BP
Dave Hayes writes: > What does the _BP extension mean on the RELENG tags? "Branch point". -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Difference between RELENG_* and RELENG_*_BP
If memory serves me right, Terry Lambert wrote: > Dave Hayes wrote: > > What does the _BP extension mean on the RELENG tags? > > Branch Point. > > It means the code has been branched, Yes. > either for a code slush, > or for other work that may not make it back in until it's > complete, which might take a while. Nope. The original poster asked about RELENG_* branches; they aren't used that way, which I'm sure you know. Anyone wanting more information about how we *really* use the RELENG_* branches should take a read through Murray Stokely's release engineering article: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/index.html Bruce. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Difference between RELENG_* and RELENG_*_BP
If memory serves me right, Dave Hayes wrote: > What does the _BP extension mean on the RELENG tags? It marks the "branch point" where the RELENG_* branch was created from the HEAD. Bruce. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Difference between RELENG_* and RELENG_*_BP
Dave Hayes wrote: > What does the _BP extension mean on the RELENG tags? Branch Point. It means the code has been branched, either for a code slush, or for other work that may not make it back in until it's complete, which might take a while. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
