Re: [GUSDEV] managing GUS releases

[Michael S. <msa...@pc...>]

Hi Fernan,

Comments below.

On 7/7/05 10:35 AM, "Fernan Aguero" <fe...@ii...> wrote:

> +----[ 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.
> 

As a matter of policy, it's my understanding that we all agree that a
particular release branch will not have any further feature development--
only bug fixes.  But I should also point out that non-urgent bugs could also
be provided in the trunk for the next release and never released as part of
a patch to the current release.

> 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.

Yes--- I think that's overkill.  After all, with subversion (which we're
using) each checkin is numerically tagged anyway.

> 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? 

The issue is that user's won't have a working copy to update-- their
original should be from the distributable.  I think downloading the updated
distributable is a trivial task, but I do agree that we could do more to
make it even easier (I'm thinking specifically here about if a file is
deleted as part of the release-- simply rerunning build GUS install -append
won't remove that file in the gus_home which could cause issues).

> 
> 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.
> 

No.  The most current version will frequently be the trunk, which may not be
stable.  If people find an issue in their release, they should:

1) Check the bug tracker to see if the issue is known and/or resolved.
    * If unknown, file a bug
    * If known, and fixed, and released: upgrade if possible
    * If known, and fixed, and unreleased: if urgent, apply patch
    * If known and not fixed: submit patch or wait


> 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.

And that's ok for people comfortable with it, but I think for most people,
the new "traditional" release/distributable paradigm will provide a better
experience.

These, of course, are just my opinions/suggests...  We should make sure the
community is comfortable with whatever the "recommended" approach is.

> 
> Fernan
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev