[707] in Release_7.7_team
Strategy for setting up the new repository
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sun Aug 11 16:09:55 1996
Date: Sun, 11 Aug 1996 16:09:45 -0400
From: Greg Hudson <ghudson@MIT.EDU>
To: release-team@MIT.EDU
Cc: saurons@MIT.EDU
These are the wrong mailing lists for me to be sending mail to.
release-team deals with the specific process of making a release, and
saurons contains many people who have little interest in the
day-to-day maintenance of the athena source tree. There is no correct
mailing list for me to send this message to, since for the past few
years the source tree has been basically one huge release branch and
actual development has taken place in disconnected projects. So I'll
start with some words on the social organization of source tree
development.
As discussed in a past meeting, we need a mailing list for people
interested in reviewing proposed source changes. My suggested name is
source-reviewers (I'm going to use "source" as a mailing list prefix
because we seem to have already claimed it in Moira, e.g. source-acl).
I think we also want a mailing list for people who plan to make
changes to the new source tree (a subset of saurons, those people with
commit access to the source tree). My suggested name is
source-developers; mail would go to this list about changes to the
organization of the tree, updates in the progress of setting it up,
changes to the build system requirements and source tree standards,
etc..
Once source-developers is set up, I plan to use it to discuss (and
schedule meetings to discuss) the build system requirements for
software we maintain as well as standards for maintaining portability.
I will not be willing to open up the source tree to wider commit
access without an interim document on coding standards. (It will take
me at least a year to visit all of the modules in /source/athena and
clean them up; we need a set of guidelines for making changes to the
existing sources.)
Now, in an effort to de-mystify what I'm going to be working on for
the next few weeks, I'll say some words about the mechanics of setting
up the new repository. Here are the steps I need to go through:
* I have to tag the 8.0 sources. (This requires checking in
all the locked files, which is mostly taken care of.)
* I need to create a place for the new repository. My current
preference is /afs/dev/source/repository, since the CVS
repository will not be version-dependent (although it won't
necessarily apply to releases 8.0 and prior; see below).
* I do not plan to incorporate modules into the repository
that we don't build any more. This will affect the
historical value of the repository, but we will be keeping
around the 8.0 source tree and RCS tree indefinitely.
* As I copy things over, I need to look for RCS files with the
default branch set, and merge those branches into the
mainline.
* I want to do a bit of reorganization in this process. Right
now the major things I want to do are:
- Collapse third/unsupported and third/supported into
"third." I think it's clear to everyone who's
worked on the source tree that third/unsupported is
a usually false and not very useful.
- Create a new hierarchy "packs" which conatins tools
for building and maintaining the packs. This would
include some stuff out of the support hierarchy
(like "wisk"), most of athena/config, and maybe
athena/dotfiles and athena/*/scripts.
The vision I had was that the athena hierarchy would
contain only software (code that function, not
stuff that sets parameters), and the packs hierarchy
would contain everything specific to how we set up
and configure that software on cluster machines.
- Most of the stuff that wouldn't move out of
"support" into "packs" is some software like imake,
which more properly belongs in athena/bin.
- Create a separate area, probably not in the
repository at all, for binaries we use from
third-party sources that aren't part of the
operating system. Right now I believe that's AFS
and nothing else.
- Move what's in the "sun4" and "sgi" hierarchies into
the "third" hierarchy, to the extent that they
contain sources we maintain from third parties.
Stuff in "packs" will decide whether to build a
given piece of software on a given platform. (Right
now we sometimes decide that in wisk, sometimes in a
piece of software's .build file, and sometimes
decide that by placement in the source tree.)
It would help if there were someone sanity-checking the
organizational changes I make. The idea is that this
reorganization should be doable very quickly
* I plan to copy the athena hierarchy more or less wholesale,
except to leave out things we don't build. For at least
some and possible all of the modules in the third hierarchy,
I want to start by importing the vendor sources (if I can
find them) and then propagate the changes we made. This
process could take me a while; the plan is that I will
un-freeze the repository before taking care of the third
hierarchy, and then if work needs to be done on a
third-party module before I've taken care of it, I can fault
it in.
After the new repository is mostly set up, my major priority is to set
up the wash process. This requires repairing the parts of the build
system which I will have broken in my reorganization, and then shaping
it up a little bit so that it can be automated. Another several
weeks.
