Re: Re: [Lnx-bbc-arch] build complete for lnx-bbc--research [main:meta/lnx-bbc], started Aug 22 at 12:00

I cannot believe Nick Moffitt said this on the ENTARNET:
> begin  Nate Riffe  quotation:
> > building file list ... done
> > lnx-bbc-i386-2004-08-22T12:06:43-0400.iso
> [...]
> > Total file size: 57114624 bytes
> 
> 	Where do these images get put these days?

The main location is http://www.movealong.org/builds/, which redirects
to http://dorothy.movealong.org/builds/.

The old autobuilder used to upload to two other locations, one of
which was somewhere on genetikayos.  I haven't implemented that or
bittorrent meta file generation in the new autobuild script yet, but I
intend to.

The research branch now builds ISOs with an updated toolchain, kernel,
and glibc.  There is an even newer compiler available now.  I don't
know whether it was available when I started the gcc-nuv--3.3 branch
and I missed it or whether it was released in the meantime, but
there's that to persue.  As it stands, though, the core system stuff
is all up-to-date.  I think now is a good time to start chasing down
newer versions of the rest of the software.

As for working on a new release, I'd like to defer any decisions to
Seth or anyone else who's inclined to manage that process, but I'll do
so with the following recommendation: that we try to stabilize the
release branch or a descendant from it to a point where we could tag a
new stable branch (lnx-bbc--stable--3.0?) in that genealogical group,
rather than from the current lnx-bbc--stable--2.1 branch.  There are a
couple of reasons why I make this recommendation, related to problems
we'd have trying to tag a new stable branch from the current one.

First of all, when we migrated from CVS to arch, the differences
between the old STABLE and HEAD branches in CVS were carried into arch
as a single changeset between lnx-bbc--research--0.0--base-0 and
lnx-bbc--research--0.0--patch-1.  Backporting that changeset piecemeal
to a family of stable branches separate from the family of research
branches will cause a lot of manual work in the long run that could be
avoided by working strictly with whole changesets.  This sort of thing
is bound to come up anyway, but I think the changeset between base-0
and patch-1 of research is a special case because it is a couple of
orders of magnitude coarser than a changeset really should be.

Secondly, the main concern with making releases from the research
branch has always been that it doesn't build on Debian stable, our
reference build system.  This will be a moot point when sarge is
released, since research has always built on sarge (when it builds at
all), and I hear that that's not too far off.

There is also the open issue of migrating from openssl to gnutls.  I
think that this is something that someone could tag a branch from
research and start working on at any time.

-Nate

-- 
--< ((\))< >----< [email protected] >----< http://www.movealong.org/ >--
pub  1024D/05A058E0 2002-03-07 Nate Riffe (06-Mar-2002) <[email protected]>
     Key fingerprint = 0DAC F5CB D182 3165 D757  C466 CD42 12A8 05A0 58E0