Re: [GUSDEV] managing GUS releases

[Fernan A. <fe...@ii...>]

+----[ Steve Fischer <sfi...@pc...> (06.Jul.2005 20:29):
|
| Fernan-
| 
| see below for response to your first point.
| 
| for your second point, i strongly urge you to cut and paste into a new 
| posting to the group with an appropriate subject.   its too important a 
| topic to be buried inside this one.

OK, will do.
 
| steve
| 
| Fernan Aguero wrote:
| 
| >Steve,
| >
| >here are my ideas about the part of your proposal that deal
| >with 'managing branches'. 
| >
| >I agree with you on the branching before release, therefore
| >freeing the main trunk for continuing development towards
| >future versions. I also agree on the 'tagging' of already
| >released branches to provide landmarks of bug fixing
| >activity. However I think that it should also be pointed out
| >that usually you don't need to wait for the release engineer
| >to post a new tarball ... in your example, people can just
| >track the '3.6' branch and get all bug fixes irrespective of
| >the minor version. Am i correct?
 
| i am not sure i understand what you mean by tracking the 3.6 branch.  
| perhaps you mean downloading from the repository directly using the 
| tag?   the one thing we don't want is for people to download and use 
| untagged versions.  then we don't know what they have, and can't 
| properly track bugs, etc
|
+----]

It's my personal bias towards a source centric view of the world :)
And it's also part of my FreeBSD heritage, where 'tracking' is
intimately related to the use of cvsup to sync sources
against a cvs repository.   
http://www.polstra.com/projects/freeware/CVSup/
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/synching.html
 
The thing I was trying to say is that once you do a major
release, the branch (3.6 in this example) does not undergo
further development. So if this is set as a policy (in
FreeBSD old releases are owned by a security officer and
normal people with commit privileges (committers) cannot
under any circumstances make changes to these branches) then
anyone 'checking out' the 3.6 branch using cvs (not the
tagged release, because there maybe bug fixes since the
release) or 'tracking' the 3.6 branch using cvsup (if you
find it useful to have a cvsupd server installed) is sure to
have the latest and most up to date version in the 3.6 line.

You might as well tag the repository for each bug that is
fixed, but this assumes that there will be little activity
... so you will have 3.6p1 (patch 1), 3.6p2, and so on. If
the activity is higher, then tagging that much maybe
overkill. The thing here is making the load lighter on the
release engineer ... just do the hard work (getting tarballs
out the door) for major releases. Users get minor releases
and bug fixes by applying patches or updating their sources
from the repository. What if you release 3.6.1 and
then notice that you missed a critical file or bug fix? You
need to do another release, 3.6.2. This is not necessary if
users checkout/track the repository. Does this sound
reasonable? 

As to the issue of users working with 'untagged' versions,
this is just a matter of educating users. And keep reminding
people on the mailing list that they should do a cvs update
(or cvsup) and check their problem against the most current
version on any branch.

Again, the idea is that the changes that go into these
'maintainance' branches should be easily applied to
production sites. They should not break anything, so there
shouldn't be a problem updating a gus installtion against
the most recent version in the same branch.

It's just a suggestion. I would always prefer to track the
3.6 branch instead of downloading separate 3.6.1, 3.6.2,
etc. versions. And of course this doesn't preclude that you
might do minor releases where appropriate.

Fernan