CVS Issues with branch.. Was: Re: HEADS UP: Be nice to -CURRENT ( "1 week Feature Slush" )
Murray Stokely wrote: > On March 15, a RELENG_5_0_DP1 branch will be created in CVS for > final release polishing. This will allow us to provide translated > release notes, sync up sysinstall and the package set, bump version > numbers, and tweak default diagnostic settings without further > impacting -CURRENT developers. Commits to this branch will require > re@ approval. Actually, with my CVS hat on, I have a *huge* problem with this. We have a large number of "temporary" repo copies in place that are to be deleted (ie: rm -rf) soon. This was with the plan that there would be *NO* persistant branches and that it would be rm'ed long before the RELENG_5 branch began. I had a quick look and I immediately found 55MB of duplicated repo files. That's over 5% of the repo right now. I want to know what expectations people have by calling this a "RELENG_5_XX" branch.. Given that this stuff is going to be rm'ed within a month, that will break RELENG_5_DP1 when that happens. People will no longer be able to cvsup or check out -r RELENG_5_DP1 and have it build. Specifically, gcc and gdb will not build. If this is going to be a "static" release (calling it RELENG_5_anything is a mistake IMHO) then this isn't a big deal. But if people are expecting it to have ongoing secirity fixes etc like we do with RELENG_4_5 etc then we have a problem, because it cannot last very long at all. Accordingly, I would much prefer that the branch (if we have to have it) would be called SNAPSHOT_5_DP1 or soemthing, so that the "RELENG_" prefix doesn't unduely raise expectations that it will keep working, or move the DP1 release elsewhere if we want it to remain cvsup'able long term. The other option is to do some hackery after the branch is set down so that the *.291 and *.295 temporary copies do not exist in the branch, and accordingly wont get broken when they are cvs rm -rf'ed. (Hmm, this might be the best option from a cvs perspective, if people dont mind the fact that -current and DP1 will have some files in different places..) Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CVS Issues with branch.. Was: Re: HEADS UP: Be nice to -CURRENT ( "1 week Feature Slush" )
[Trimming Cc list a little bit] If memory serves me right, Peter Wemm wrote: > Actually, with my CVS hat on, I have a *huge* problem with this. In the future, if you see such huge problems come up, a little more advance notice might be nice. :-( > We have a large number of "temporary" repo copies in place that are to > be deleted (ie: rm -rf) soon. This was with the plan that there would > be *NO* persistant branches and that it would be rm'ed long before the > RELENG_5 branch began. Is there more to this plan? This is news to me and I would like to get up to speed. > I had a quick look and I immediately found 55MB of duplicated repo files. > That's over 5% of the repo right now. > > I want to know what expectations people have by calling this a > "RELENG_5_XX" branch.. Given that this stuff is going to be rm'ed within a > month, that will break RELENG_5_DP1 when that happens. People will no > longer be able to cvsup or check out -r RELENG_5_DP1 and have it build. > Specifically, gcc and gdb will not build. > > If this is going to be a "static" release (calling it RELENG_5_anything is > a mistake IMHO) then this isn't a big deal. But if people are expecting > it to have ongoing secirity fixes etc like we do with RELENG_4_5 etc then > we have a problem, because it cannot last very long at all. Differences of opinion on naming aside...the branch isn't supposed to last long at all. The point is to provide a slightly polished snapshot to the wider developer community. We can't do the QA/releng work on HEAD without calling for a code freeze (which we early on decided that we would *not* do). Since it's not a formal release, we won't be doing security fixes, etc. I can't imagine why anyone would expect to cvsup this thing at some point in the distant future, especially after 5.0-DP2 and 5.0-RELEASE. Just thinking off the top of my head, having it break soon after 5.0-DP1 might not be fatal, as long as we have the CDROM and FTP areas still intact. Did you have a definite date for the rm-ing in mind? Thanks, Bruce. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CVS Issues with branch.. Was: Re: HEADS UP: Be nice to -CURRENT ( "1 week Feature Slush" )
"Bruce A. Mah" <[EMAIL PROTECTED]> writes: > Differences of opinion on naming aside...the branch isn't supposed to > last long at all. The point is to provide a slightly polished snapshot > to the wider developer community. We can't do the QA/releng work on > HEAD without calling for a code freeze (which we early on decided that > we would *not* do). Then you don't need a branch, you just need a simple tag, and you can slide it forward if something needs fixing, and remove it after rolling and shipping the snapshot. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CVS Issues with branch.. Was: Re: HEADS UP: Be nice to -CURRENT( "1 week Feature Slush" )
On Thu, 14 Mar 2002, Bruce A. Mah wrote: > I can't imagine why anyone would expect to cvsup this thing at some > point in the distant future Rule number one of release engineering... user's will do all kinds of wacky stuff that you would never expect them to do, and complain bitterly when it doesn't work. :) -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CVS Issues with branch.. Was: Re: HEADS UP: Be nice to -CURRENT ( "1 week Feature Slush" )
On 15 Mar 2002, Dag-Erling Smorgrav wrote: > "Bruce A. Mah" <[EMAIL PROTECTED]> writes: > > Differences of opinion on naming aside...the branch isn't supposed to > > last long at all. The point is to provide a slightly polished snapshot > > to the wider developer community. We can't do the QA/releng work on > > HEAD without calling for a code freeze (which we early on decided that > > we would *not* do). > > Then you don't need a branch, you just need a simple tag, and you can > slide it forward if something needs fixing, and remove it after rolling > and shipping the snapshot. No, in this case that doesn't help. What we want is to grab a stable moment, then to allow development to continue. However, we may then want to tweak that stable moment without impinging on development, which requires a branch. The QA/releng work requires us to modify the stuff being released following the branchpoint. It's worth noting, BTW, that originally the release engineering team planned to use Perforce for this to avoid the branch issue entirely, minimize impact on the main tree, etc, but decided not to due to the high volume of complaints on the topic. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CVS Issues with branch.. Was: Re: HEADS UP: Be nice to -CURRENT ( "1 week Feature Slush" )
Robert Watson <[EMAIL PROTECTED]> writes: > It's worth noting, BTW, that originally the release engineering team > planned to use Perforce for this to avoid the branch issue entirely, > minimize impact on the main tree, etc, but decided not to due to the high > volume of complaints on the topic. If it allows you to do your job better and quicker, use it. I was actually going to suggest it myself, but I didn't think anybody would take me seriously... DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CVS Issues with branch.. Was: Re: HEADS UP: Be nice to -CURRENT ( "1 week Feature Slush" )
On Thu, Mar 14, 2002 at 09:36:30PM -0500, Robert Watson wrote: > It's worth noting, BTW, that originally the release engineering team > planned to use Perforce for this to avoid the branch issue entirely, > minimize impact on the main tree, etc, but decided not to due to the high > volume of complaints on the topic. You would get no complaints from me. I think this would be a very good use of Perforce. In the past the WC -CURRENT snapshots were not tagged or branched w/in CVS. I don't see that the requirement to do so has been demanded. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CVS Issues with branch.. Was: Re: HEADS UP: Be nice to -CURRENT ( "1 week Feature Slush" )
> > "Bruce A. Mah" <[EMAIL PROTECTED]> writes: > > > Differences of opinion on naming aside...the branch isn't supposed to > > > last long at all. The point is to provide a slightly polished snapshot > > > to the wider developer community. We can't do the QA/releng work on > > > HEAD without calling for a code freeze (which we early on decided that > > > we would *not* do). > > > > Then you don't need a branch, you just need a simple tag, and you can > > slide it forward if something needs fixing, and remove it after rolling > > and shipping the snapshot. > > No, in this case that doesn't help. What we want is to grab a stable > moment, then to allow development to continue. However, we may then want > to tweak that stable moment without impinging on development, which > requires a branch. Not necessarily. What we've done at work is *NOT* create a branch unless absolutely necessary. The only time a branch is requires is *if* a file changes out from underneath the developer *AND* it that files needs modifying but *must not* contain that same change. We play it by ear, since in almost all cases, the change can be made to any necessary file(s) and the file(s) updated by hand. Otherwise, often the change that happens are necessary to merge into the build, so we do an update. Only in very rare cases do we run into a problem where we have to create a branch. In that case, the developer responsible for the release creates a branch from his checked out tree (there's no law against creating a branch from sources that are older than the HEAD), and then makes any necessary changes. It's *not* that hard to do. Otherwise, once the release is made using the files, a point-tag is laid down and we've saved the hassle of the branch. > The QA/releng work requires us to modify the stuff being released > following the branchpoint. See above. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CVS Issues with branch.. Was: Re: HEADS UP: Be nice to -CURRENT ( "1 week Feature Slush" )
On Fri, Mar 15, 2002 at 03:32:00AM +0100, Dag-Erling Smorgrav wrote: > "Bruce A. Mah" <[EMAIL PROTECTED]> writes: > > Differences of opinion on naming aside...the branch isn't supposed to > > last long at all. The point is to provide a slightly polished snapshot > > to the wider developer community. We can't do the QA/releng work on > > HEAD without calling for a code freeze (which we early on decided that > > we would *not* do). > > Then you don't need a branch, you just need a simple tag, and you can > slide it forward if something needs fixing, and remove it after > rolling and shipping the snapshot. Sliding tags around at the request of hundreds of different developers making thousands of changes to -CURRENT over that time period is not very appealing. However, all of our other options are rapidly being shot down as well. Peter raises some valid concerns about the pains that branching CVS will cause. They would have been much more helpful if voiced to re@ a week ago, but that's another issue. At the very least a tag is going down in approximately 24 hours. - Murray msg36135/pgp0.pgp Description: PGP signature
Re: CVS Issues with branch.. Was: Re: HEADS UP: Be nice to -CURRENT ( "1 week Feature Slush" )
On Thu, Mar 14, 2002 at 04:40:08PM -0800, Peter Wemm wrote: > If this is going to be a "static" release (calling it RELENG_5_anything is > a mistake IMHO) then this isn't a big deal. But if people are expecting > it to have ongoing secirity fixes etc like we do with RELENG_4_5 etc then > we have a problem, because it cannot last very long at all. Ongoing security fixes for a SNAPSHOT ??? No, that is definitely not the case. > Accordingly, I would much prefer that the branch (if we have to have it) > would be called SNAPSHOT_5_DP1 or soemthing, so that the "RELENG_" prefix > doesn't unduely raise expectations that it will keep working, or move the > DP1 release elsewhere if we want it to remain cvsup'able long term. I think that the huge warning signs all over the release documentation will do a lot more to set the expectations that the name of a CVS tag, but just to be sure I suppose we can keep the RELENG namespace for official releases. Your proposed name change works for me. - Murray msg36136/pgp0.pgp Description: PGP signature
Re: CVS Issues with branch.. Was: Re: HEADS UP: Be nice to -CURRENT ( "1 week Feature Slush" )
On Thu, 14 Mar 2002, Nate Williams wrote: > Only in very rare cases do we run into a problem where we have to create > a branch. In that case, the developer responsible for the release > creates a branch from his checked out tree (there's no law against > creating a branch from sources that are older than the HEAD), and then > makes any necessary changes. It's worth noting that the rationale for the branch was that we *want* -CURRENT development to continue at a wild and merry pace, and *expect* that it will. Once the branch occurs, Jeff is free to replace the kernel memory allocator, etc. Local tweaks on the branch may include backing out some of the more recent changes to locking (the VM changes, for example -- there have been some reports of stability problems from Alfred). I.e., there is a specific development process goal to be accomplished using the branch. My feeling is that at this point, we probably should just use Perforce due to limitations in CVS. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CVS Issues with branch.. Was: Re: HEADS UP: Be nice to-CURRENT ( "1 week Feature Slush" )
At 2:17 PM -0500 3/15/02, Robert Watson wrote: >My feeling is that at this point, we probably should just use >Perforce due to limitations in CVS. This seems fine to me. I am uneasy about perforce in cases where someone is developing something which is *meant* to be merged back into the main branch, and anyone interested in that change is told "just check the P4 repository". That is not what is happening here. I would not *push* to have this done in P4, but I certainly do not mind if the RE team wants to handle it that way. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
