Todd Vierling <tv@wasabisystems.com> wrote:
>On Sat, 18 Nov 2000, John Darrow wrote:

>: Now wait a minute, have we completely dismissed the use of 'sup' for
>: tracking our source tree, in favor of AnonCVS?

>No; however, "sup" follows "the latest source".  If you want "exactly" 1.5,
>there have been tarballs created for that purpose that will go with the 1.5
>release, or you can now use anoncvs.

Yes, but then I'd have to download and extract yet _another_ source tree,
and also extract and apply any local patches to that (for example: ever try
rwho -a on an i386 with users idle more than an hour?  Ugly gcc -O2 optimizer
bug, and, yes, it's been send-pr'ed, port-i386/8364, Havard even applied the
workaround patch into 1.4.2, but it apparently never made it into
then-current (which became 1.5)).  Though this is _possible_, it's a pain,
and requires much additional disk space and time.

>In fact, 1.5.1 pullups will start
>going in on Monday.  (This is in an effort to get 1.5.1 out the door on a
>much shorter time schedule than past patch releases--as early as January or
>February.)

I'm not at all against getting patch releases out quickly... but couldn't
the update of osrelease.sh, etc. have waited until the first patch went in
today (Sunday), at least giving _one_ clean supscan with 1.5 (including the
"last minute fix")?  Even a few hours would have allowed the Saturday
morning supscan to complete.  Instead, today's sup gives me something that is
codewise _exactly_ 1.5, but says "1.5.1_ALPHA" everywhere.  And despite how
much _I_ know about its stability, that doesn't inspire confidence when seen
by others on production machines.

Thus if I want a locally fixed 1.5, I now have three choices:
 1. use friday's sup/import, adding the last minute fix as a patch
 2. use today's sup/import, reverting the osversion stuff as patches
 3. download and extract yet _another_ set of tarballs, extracting all
local patches from local cvs and applying them to the extracted source tree

All three choices are sub-obtimal.

>:  Typically we've left the
>: branch as-is for at least a few days to allow release builds.
>: (Yes, I know how to use AnonCVS, but for simple tracking, and
>: _especially_ for importing into a local CVS tree (for tracking local
>: changes), sup is a much simpler and much more lightweight method.)

>Official release builds aren't supposed to use sup.  If you want to do a
>build based on "the release" that is not using the officially released
>binaries, the only _truly_ supported method is downloading the source/sets
>tarballs shipped with "the release."  Sup is basically a means of tracking
>the latest source, be it release branch or current.

But the "latest" source would _always_ be current (AKA cvs HEAD), never
anything on the release branch.

The entire precedent behind switching sup to the release branch during
the release cycle is so that the release gets as much testing as possible,
from people who are not necessarily developers but have been tracking
current up until that point, and who may very well decide that that release
has what they need for their system.  Forcing them to have to download yet
_another_ set of tarballs if they want to build from source is, IMHO, wrong.

>Now, with that said, I wasn't personally aware that people were actually
>trying to do _exact_ "release" builds off of sup.  I can provide the list of
>what needs to be reverted, if you'd like; however, I now plan to look at
>this process a little more closely for 1.5.1.

At least one developer has responded that he has, in fact, been building
releases from sup.  And I can pull the list of changes from source-changes.

The issue is that there's been a precedent in place for a long time that
sup (and ftp and tarball) current follows the release branch during the
release cycle.  And, at least before this time, it's always _stayed at the
release point_ for a few days, after which there has _always_ been a big
announcement warning that it will be reverting back to true -current.
Changing this precedent should have been discussed _somewhere_ first
(probably on current-users), or at the very least, announced significantly
beforehand.  Instead, we're left with a sup "current" which now points down
a release branch _beyond_ the official release...

>: And speaking of which, traditionally the 'current' branch of sup has
>: followed the release cycle and then returned to current a few days after
>: the official release.  But during the past year we added the 'release'
>: branch to sup, which followed the netbsd-1-4 branch.  What now?  Does
>: 'current' revert to real current, and 'release' jump to netbsd-1-5 branch
>: (thus causing a huge surprise for those who have been tracking 1.4.3 that
>: way), or are we adding a new 'release-1-5' branch, or are we discounting
>: sup altogether (as the above timing could suggest)?

>There's a lot to this, particularly because we are trying to aim for a much
>shorter branch-to-release cycle than we've had in the past as well.  I can
>conceivably see all of 1.5, 1.6, 1.7, and -current being actively maintained
>simultaneously for releases in the next year.

>We should probably do something a little more uniform here, by creating sup
>collections that follow the release branches explicitly.  "current" would
>then _always_ follow -current, and we would have "release-1-5",
>"release-1-6", etc.

This I'm all for.  We should probably then add 'release-1-4' as the name
for what is now "release" (e.g. netbsd-1-4 branch) and eventually deprecate
the old unqualified 'release' tag in order to reduce the surprises for
people who have been tracking it.

I'm mainly saying, let's not treat sup in a substandard way just because
we've got AnonCVS available.  Otherwise, we might as well just junk sed,
awk, etc. for perl...  (No, that is _not_ a suggestion...)

jdarrow

-- 
John Darrow - Senior Technical Specialist               Office: 630/752-5201
Computing Services, Wheaton College, Wheaton, IL 60187  Fax:    630/752-5968
Alphapage: 6303160707@alphapage.airtouch.com            Pager:  630/316-0707
Email:     John.P.Darrow@wheaton.edu