arch time, folks!

begin  Paul Gray  quotation:
> Log Message:
> Adding -D__KERNEL__ to CFLAGS pushes this through on my 2.6.x build box.
[...]
> RCS file: /usr/local/var/cvs/gar/disk/hdparm/Makefile,v
[...]
> +CFLAGS += "-D__KERNEL__"

	Okay, so I'd love to do a coordinated roll-out of this thing,
but we've kind of caught a good wind today.  You may or may not know
this, but we've been seriously contemplating a switch from CVS to
arch.

	It started a few months ago when Zack Brown came into #lnx-bbc
and tried to sell us on it.  We were skeptical of the supposed
benefits, since it seemed like our problem was a miscommunication
about the role of "HEAD" in a world with "STABLE".  

	However, we've had some time to stew over this, and it turns
out that Zack was really on to something.  In particular, arch may in
future help us to coordinate with other GAR-using projects.  But there
are many ways in which it can help us now:

DISTRIBUTED BRANCHES:

	Arch is a distributed system, so we have set up two "blessed"
branches on gargoyle:  lnx-bbc--stable--2.1 and
lnx-bbc--research--0.0.  lnx-bbc--stable--2.1--patch-1 is equivalent
to STABLE in cvs, and research is equivalent to HEAD.  In order to do
development, typically you will branch off one of these into an
archive on your own machine (laptop, desktop, or even a homedir on
gargoyle).  Once you have completed a sizeable feature, you just
star-merge your work into the blessed branch and commit up to
gargoyle.

	This means that Nate can maintain five or six lines of
development on the research side, and that we can all do work on our
laptops without needing a network connection to gargoyle.

CHERRY-PICKING:

	Arch uses a concept of changesets, which is refreshing after
wrangling with CVS's diff-per-file and diff-per-directory approach.
All changes are one-feature, one-changeset.  So if Seth checks in an
NUV to stable to make it patch-72, Nate can easily replay patch-72
onto the research branch and let all research developers get it on the
next update.  

MIRRORS:

	Since arch uses HTTP for read-only access, we can just put up
mirrors on the web space.  In fact, the archives themselves are
currently Web-accessible for those who need them.  I plan to change
the build script to actually perform a bit of quarantine:  only
changesets that result in a functioning build will be pushed to the
public read-only stable archive.  

	This archive will also live on genetikayos, which has a much
faster pipe.  This means that third-party developers who track the
stable arch code will have fast downloads of known-good code.  This is
a big deal given our problems with build environments.

DELTAS:

	The mechanisms available to third-party developers using
read-only downloads are much better than CVS's.  Rather than sending
us big diffs, a rich delta tarball can be created for us to merge into
our code.

SIGNATURES:

	The archive we set up uses gpg signatures on all modifications
of the tree (checkins, cacherevs, etc).  This means that we'll have to
set up a keyring of trusted signatures, but the result is that we will
have better verification of who worked on what changesets.

PROBLEMS:

	The arch model is different from cvs, specifically in that
there is no such thing as an arch *server*.  This means that all
configuration happens on the client end.  The effects of this are:

	Scripts such as the mail script that generated the mail I'm
replying to would need to be installed on each developer's machine in
a very specific way.

	There's a bit of a learning curve to arch, but I hope to write
a few HOWTOs that will apply to very specific circumstances in the
LNX-BBC development process.  Since a lot of work happens on the
client side, there is a little more configuration work to be done on
client systems.

Finally, I'd like to ask that we put a bit of a freeze on CVS so that
we can dive head-first into arch.  I realize that it's a sudden move,
but development is picking up and we ought to do it before we hit such
a rapid pace of development that we find a move impractical.

If you need help, please feel free to drop by #lnx-bbc on slashnet
IRC, and yosemite and I can walk you through getting started.  I will
try to send a HOWTO to this list as soon as possible.

-- 
"virii" would be the plural of the mythical masculine         Nick Moffitt
noun "virius". The neuter plural of "virus" would be         [email protected]
"virora" (as "opus" & "opera"), and "viri" is the plural
of the masculine "vir" (man). It really is "viruses"!