[1495] in NetBSD-Development
Meeting results
daemon@ATHENA.MIT.EDU (Greg Hudson)
Thu Nov 13 22:59:15 1997
Date: Thu, 13 Nov 1997 22:58:50 -0500 (EST)
From: Greg Hudson <ghudson@MIT.EDU>
To: sipb-athena@MIT.EDU
Well, we had a productive flame session. I elected to eat dinner
instead of taking written minutes, so here is a summary based on
memory:
Tie-in with Linux work
----------------------
I brought up the question of whether having a unified source tree
carries many advantages, if we're going to keep in close sync with the
Athena tree. After some discussion, it seemed like it is still a good
idea to have a unified tree if we can maintain a certain amount of
discipline.
What we're planning to do, which people seemed to think is reasonable,
is set up a repository focusing on NetBSD work, and then after the
1.3-based release is out, we can add Linux people to the acls and
invite them to do work there if they want. Since there aren't a whole
lot of people doing active work right now, I didn't see this as
causing a problem.
Sal already has a repository set up in source-sipb, but I'm not sure
if his vision is quite compatible with mine.
Work setup
----------
The general idea is that SIPB has a separate repository which does
imports of the mainline sources. Hopefully, functional improvements
will be done on the Athena mainline (or rapidly propagated back in)
and only porting work will be done in SIPB's repository. I was
looking at maybe two or three total imports before the upcoming
release, and then maybe monthly imports after that, assuming we find
the person-hours to do that. We shouldn't have any trouble importing
individual files for important changes.
Code review: the Athena source-reviewers model has been very
successful so far. It doesn't catch everything (we can't force people
to review code they don't understand), but it helps prevent projects
from becoming either one-person wonder or becoming incohesive and
undisciplined. From discussion on this point, what I came away with
is that we will create a list ("sipb-source-reviewers", maybe) and
local modifications in our repository will be reviewed on that list
before being committed. Marc suggested that having development
branches for big projects is important, and I agree. However, so far
we haven't had a need for them in the Athena source tree, and I don't
anticipate a need for them here.
Locations of materials: we have several pieces to worry about:
* A repository (will start at about 200MB and grow; Athena's
is 238MB right now)
* Working directories for people (about 200MB for each full
tree, much less for partial trees)
* One or two checked out working directories which people
aren't supposed to touch (the mainline and the first release
branch)
* A release build directory (Solaris's is 350MB)
* System packs (Solaris's is 170MB)
System packs really want to live in the sipb cell because we need s:a
bits there. We don't need s:a bits on the build tree, so everything
else can live in the dev cell. Since we're looking at about a 1.2GB
initial investment plus 0.2GB per active developer (~3 of those),
putting everything but the packs in the dev cell (where space is less
tight) would probably be a big win.
Machine resources: I identified four roles for machines which we
probably want to support:
* A build machine for folks building things in lockers.
planet-zorp, basically.
* A crash and burn machine, probably lola-granola.
* A machine for building the release, and for making patch
releases
* A washing machine
During a release testing cycle, we don't really need a washing
machine, and outside of a release testing cycle, the locker-building
machine can double as a release-building machine. So we only need
three machines, two of which SIPB can provide. IS can probably
provide the third one (equal-rites, in my office). It can be a
remotely accessible machine; maybe if SIPB gets the rack set up, we
can think about housing more Intel-based machines in the office.
Version numbers: Right now we're at 7.7.2, using a version numbering
system which hasn't worked very well. If we're going to be using
Athena tools like getcluster and the update script, we need to fit
into the Athena version numbering scheme (three numbers, first two for
rebuilds of the packs and the third one for patch releases). We may
want to do multiple packs rebuilds between versions of Athena (e.g. if
NetBSD actually starts doing three releases per year), so following
Athena release minor numbers may not be such a hot idea. After some
discussion, we decided that the least of all evils is to number the
NetBSD-Athena release at 8.0.0, and track the Athena major number but
not the minor one.
Work breakdown
--------------
We need to:
* Finish porting athena-hierarchy programs in the Athena
mainline, with a few exceptions (xdm, machtype).
* Finish up some tree work to make the Athena mainline more
ready for cutting a release.
* Set up new repository (and any associated mailing lists, pts
groups, working direcetories, etc.).
* Port the exceptions in the new repository (basically, bring
in patches and stuff from the old sipb-athena).
* Port the third-party stuff (already all done, I think).
* Set up configs et al in packs hierarchy. This is where the
work of constructing the port really happens. The hardest
part is probably thinking about what happens at boot time
and maybe constructing an analogy to syncconf.
* Worry about updating from 1.2 systems. We can punt this if
we really want to; we did for the 1.2 port.
* Worry about the update system for the future. We can delay
this until later. It's a hard problem with such a diverse
hardware environment. If we can construct an SSTO-like
kernel to boot off of, we can do updates fairly safely.
* The install. We have an install system; we need to
integrate it with NetBSD 1.3 (using the new ramdisk support,
and *maybe* eliminating the NFS server) and also modify it
to do more Athena-like things (construct an rc.conf file,
etc.)
* mkserv (at least "mkserv remote") would be really nice. One
tie-in with this is some kind of "mkserv laptop" for
disconnected operation.
The first two items are pretty much definitely mine. The remaining
items are up for grabs; Nathan has suggested an interest in working on
the install and update stuff, and I think he's also interested in
disconnected operation.
