Re: [GUSDEV] managing GUS releases

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

+----[ Michael Saffitz <msa...@pc...> (08.Jul.2005 11:01):
|
| Hi Fernan,

Hi Mike,

[snipped]
 
| > 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.

Of course. This will be ultimately driven by usage of past
releases. If newer releases are not widely adopted, or take
some time to get into production sites then probably there
is more pressure to merge fixes back.  

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

You mean that the whole branch gets tagged for a commit to
one or more files? That is overkill, but since subversion is
doing it ... it's fine then. Users can then use these
'patchlevel' numbers to get to a specific patchlevel or
revision?

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

OK, so maybe this is my bias as a heavy user of cvsup. Given
any working copy (even those obtained from distributables)
cvsup can update it to any given cvs tag/branch as specified
in a config file. cvsup will take care of deleting files
that were deleted in the repository (but it will not
delete files created locally by the user). 

So instead of downloading distributables you just specify
tags/branches in your cvsup config file, point cvsup to the
local directory where the files live, and run cvsup from
cron (every day, every week) or manually. If bug fixes are
rare, you cvsup manually every time there's a bug fixed
announced. If bug fixes are more frequent, you run cvsup
from cron.

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

Yes I know, I meant the latest code for any branch the user is
interested in. The trunk will be the most current
*development* version, updating or tracking against the 3.6
branch (or any branch) will get youthe most current version in
that branch. If I'm using a previous release (say 3.5), and
I want to report a bug or problem with this code, I have to
make sure that I have the latest 3.5 code, so I have to
update my working copy (using either a 3.5.x distributable
if it exists, or cvs/cvsup against the 3.5 branch). 

I guess that we're trying to say the same thing: 
 
| 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

only that your third step (if urgent, apply patch) is what
you do when you checkout/update to the latest code in a *branch*.
The alternative here is if the bug was committed to trunk but
not merged into other branches.   

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

Of course, as I said, even if you do the work of providing
point releases for bug fixes, users can always check out
code from the repository either for the tagged point
release, or from any branch (3.5, 3.6). So it's not
something that we should decide or vote on ... it will be
there anyway. 

I'm just trying to point out that the way of
tracking or following a stable branch should be
documented, because if users know about it and feel
comfortable with this way of working, there's less need for
providing minor point releases, which should probably help
you guys have more time for other things. 

On a side note, I just noticed that there is no cvsup
equivalent yet for subversion repositories ... :( 
Hopefully, one will be developed soon.

Fernan

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