Re: [boost] New release procedure?

2003-03-06 Thread Beman Dawes
At 11:35 AM 3/5/2003, David Abrahams wrote:

 The multiple merge thing is probably much less of an issue when
 working from trunk to branch, but it still could be useful to have
 the tag.  I would call the tag merged_to_branch name.

 So this is something each developer would do when merging to
 the branch from MAIN if they want 'extra' information
 in CVS about where the merge took place?  If this is
 correct, I'm generally opposed to this extra step as
 I don't see what it is going to buy you above and beyond
 what you can get in CVS log command.  Am I missing
 something?

If you make a big change on the trunk and need to merge to the
branch, and then you do it again, you want

 cvs merge -jmerged_to_RC_whatever -jHEAD

In order to make the merge work properly.  If the release manager
doesn't tag the head at the merge point, the first person to merge
from trunk to branch messes up that arrangement.
OK, I've added the tag merged_to_RC_1_30_0 to the CVS at the appropriate 
point in time.

It took a couple of hours experimenting with the sandbox to figure out how 
to do this correctly. WinCVS (and presumably cvs itself) seems to report 
time as UTC, but expects input times to be local.

The tagging itself took over an hour even though SourceForge CVS seemed to 
running very quickly this morning on other operations.

--Beman

___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


Re: [boost] New release procedure?

2003-03-06 Thread Beman Dawes
At 11:38 AM 3/6/2003, Beman Dawes wrote:

At 11:35 AM 3/5/2003, David Abrahams wrote:

  The multiple merge thing is probably much less of an issue when
  working from trunk to branch, but it still could be useful to have
  the tag.  I would call the tag merged_to_branch name.
 
  So this is something each developer would do when merging to
  the branch from MAIN if they want 'extra' information
  in CVS about where the merge took place?  If this is
  correct, I'm generally opposed to this extra step as
  I don't see what it is going to buy you above and beyond
  what you can get in CVS log command.  Am I missing
  something?
 
 If you make a big change on the trunk and need to merge to the
 branch, and then you do it again, you want
 
  cvs merge -jmerged_to_RC_whatever -jHEAD
 
 In order to make the merge work properly.  If the release manager
 doesn't tag the head at the merge point, the first person to merge
 from trunk to branch messes up that arrangement.
more/release_procedures.htm has been updated to reflect these discussions.

The changes to more/release_procedures.htm were made on the main trunk, and 
then merged into RC_1_30_0, and the process repeated several times as the 
instructions were refined and corrected.

In other words, the procedure was applied to its own documentation:-)

At least in WinCVS, this was a good deal easier than the old way IMO.

Please take a look at more/release_procedures.htm and suggest any 
corrections necessary.

Thanks,

--Beman

___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


Re: [boost] New release procedure?

2003-03-05 Thread David Abrahams
Beman Dawes [EMAIL PROTECTED] writes:

 At 09:53 AM 3/4/2003, Jeff Garland wrote:

  Right, sorry for dropping this.  As I recall I was hoping for
   someone more
  expert with WinCVS and some of the other tools to fill in the details
  of how to make changes.
  ... The basic CVS procedure for developers looks like it is in
  place.  I don't think the WinCVS procedure was updated.

 OK, I'll commit your changes and then add my interpretation of how it
 would work on WinCVS. But I need to get answers from Dave first. See
 below.

   I'd really like it to include the Release Procedures for the Release
   Manager, which is currently blank. While I understand the general
 idea,  I'm
   not sure what the release manager does differently. How is the branch
   named? What is the tag that goes on the main trunk and how is it named?
  
  There never have been procedures for the release manager, but they would
  be basically the same as today.  I would expect we would name branches
  exactly as we do now.  There may be some detail about how the
  branch has to be created, but other than that it would be the same.

 What is confusing me is Dave Abrahams' comment of a day or so ago:

  Didn't we agree that we were going to tag the trunk and generally do
  any merges from the trunk to the branch?  This tag appears to be on
  the branch AFAICT.

 Dave, what did you mean by that? It sounds like you expect the
 RC_1_30_0 tag to go on the main trunk and some other tag on the
 branch. 

No.

 What is the point of that? How are the tags used?

The point is that if there are multiple merges from the trunk to the
branch, you'll need something to mark the version on the trunk of the
previous merge.  At the point you first create the branch, the
previous merge point is the same as the branch point.

The multiple merge thing is probably much less of an issue when
working from trunk to branch, but it still could be useful to have
the tag.  I would call the tag merged_to_branch name.

Does that clear up my concern?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


Re: [boost] New release procedure?

2003-03-05 Thread Beman Dawes
At 09:50 AM 3/5/2003, David Abrahams wrote:

Beman Dawes [EMAIL PROTECTED] writes:

...
 Dave, what did you mean by that? It sounds like you expect the
 RC_1_30_0 tag to go on the main trunk and some other tag on the
 branch.

No.

 What is the point of that? How are the tags used?

The point is that if there are multiple merges from the trunk to the
branch, you'll need something to mark the version on the trunk of the
previous merge.  At the point you first create the branch, the
previous merge point is the same as the branch point.
Ah! That makes sense.

The multiple merge thing is probably much less of an issue when
working from trunk to branch, but it still could be useful to have
the tag.  I would call the tag merged_to_branch name.
OK, I'll add that to the procedure.

Does that clear up my concern?

Yes, thanks. I'll aim to get the new tag and procedure page in place later 
today.

--Beman

___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


Re: [boost] New release procedure?

2003-03-05 Thread David Abrahams
Jeff Garland [EMAIL PROTECTED] writes:

  What is the point of that? How are the tags used?
 
 The point is that if there are multiple merges from the trunk to the
 branch, you'll need something to mark the version on the trunk of the
 previous merge.  At the point you first create the branch, the
 previous merge point is the same as the branch point.
 
 The multiple merge thing is probably much less of an issue when
 working from trunk to branch, but it still could be useful to have
 the tag.  I would call the tag merged_to_branch name.

 So this is something each developer would do when merging to
 the branch from MAIN if they want 'extra' information 
 in CVS about where the merge took place?  If this is 
 correct, I'm generally opposed to this extra step as
 I don't see what it is going to buy you above and beyond
 what you can get in CVS log command.  Am I missing
 something?

If you make a big change on the trunk and need to merge to the
branch, and then you do it again, you want

 cvs merge -jmerged_to_RC_whatever -jHEAD

In order to make the merge work properly.  If the release manager
doesn't tag the head at the merge point, the first person to merge
from trunk to branch messes up that arrangement.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


Re: [boost] New release procedure?

2003-03-05 Thread Jeff Garland


 The multiple merge thing is probably much less of an issue when
 working from trunk to branch, but it still could be useful to have
 the tag.  I would call the tag merged_to_branch name.

OK, I'll add that to the procedure.

 Does that clear up my concern?

Yes, thanks. I'll aim to get the new tag and procedure page in place 
later 
today.

Just to be clear on my previous post, I'm asking 
for clarification on the benefits and need to complicate
the procedure from it's current form.  But please, if you
see an advantage don't let my questions stop you from
moving forward. 

Jeff






___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


RE: [boost] New release procedure? [was: 1.30.0 branch-for-releasecomplete]

2003-03-04 Thread Jeff Garland
 No one disagreed with this assessment.
 
 Jeff Garland posts a partially updated set of developer procedures:
 http://aspn.activestate.com/ASPN/Mail/Message/1411802/release_procedures.htm
 
 At this point the discussion fragments into details and corner cases. The 
 updated release_procedures.htm was never committed to CVS.

Right, sorry for dropping this.  As I recall I was hoping for someone more
expert with WinCVS and some of the other tools to fill in the details
of how to make changes. 
 
 So, if we are going to do merges from the trunk to the branch for 1.30.0 we 
 need a finalized procedure right away. Jeff? Dave?

That's true.  The basic CVS procedure for developers looks like it is in 
place.  I don't think the WinCVS procedure was updated.

 I'd really like it to include the Release Procedures for the Release 
 Manager, which is currently blank. While I understand the general idea, I'm 
 not sure what the release manager does differently. How is the branch 
 named? What is the tag that goes on the main trunk and how is it named?

There never have been procedures for the release manager, but they would 
be basically the same as today.  I would expect we would name branches
exactly as we do now.  There may be some detail about how the
branch has to be created, but other than that it would be the same.

Jeff
___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost