On mån, 2008-09-15 at 00:37 +1200, Amos Jeffries wrote:
> So it sounds like we are clear to start this immediately following a
> source format and testing of HEAD.
branching is clear to start whenever you feel the tree is in a suitable
startingpoint for aiming to get a STABLE after bugfixing and revokation
of changes deferred to the next release..
> Henrik, can you let me know what the branch tasks are that I have to
> perform, and if there are any I don't have permissions for, when it
> would be convenient for them to happen?
* Ask everyone to defer commits for a while. Not because the branching
as such, but to avoid races in the changesets browser maintenance (see
below). It's easy to recover should something screw up here however.
* Create the bzr branch using your account.
[below here as squidadm]
* Create a Versions/v3/3.1/ folder and populate it with the HTML
templates and scripts.
* Run the Versions/v3/HEAD/changesets/.update script to update the
changesets
* Copy HEAD/changesets/ to 3.1, and tie it to the new branch
echo /bzr/squid3/branches/SQUID_3_0 >changesets/.bzrbranch
* Remove all changesets from HEAD/changesets to mark te new
"startingpoint".
* Notify others than it's ok to commit to trunk again.
* Edit the squidadm crontab accordingly
* Edit trunk/mksnapshot-cron.sh to activate snapshots of the new release
Note: When you back out stuff from 3.1 which gets deferred för the next
release then remember to move the corresponding changesets back to HEAD
so it gets reclassified as work "after" the branch..
That's it I think.
Regards
Henrik
Received on Sun Sep 14 2008 - 14:48:39 MDT
This archive was generated by hypermail 2.2.0 : Sun Sep 14 2008 - 12:00:04 MDT