[1178] in NetBSD-Development
Re: sis script
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sat Jan 6 13:59:41 1996
To: Yoav Yerushalmi <yoav@MIT.EDU>
Cc: netbsd-dev@MIT.EDU
In-Reply-To: Your message of "Sat, 06 Jan 1996 12:47:10 EST."
<199601061747.MAA26951@i-see-everything-twice.MIT.EDU>
Date: Sat, 06 Jan 1996 13:59:08 EST
From: Greg Hudson <ghudson@MIT.EDU>
> However, I have not installed it in /usr/athena/bin/sis, since greg
> has suggested that we do not change /usr/athena/bin frivolously.
That only applies to the new system packs in
/afs/sipb/system/i386_nbsd1/srvd.77.1, because I want to be absolutely
sure I know about changes there and to be sure that permissions,
owners, etc. are correct. Changes to the old
/afs/sipb/system/i386_nbsd1/usr/athena are okay at this point.
I've installed the new sis script in the old /usr/athena, and I've
also installed it in the new one (which is okay since we're still in
testing). Basically:
* The old /usr/athena isn't being release-engineered, so you
can modify it; update the source tree and send mail when you
do so.
* While we're still testing the new /usr/athena, we can make
modifications to it but I want to be the one to do so so
that I can make sure I know what goes into that release.
* After the new /usr/athena is out of testing, nobody will
have write access to it and we'll use /srvd/patch for
changes like this until we do a "letter bump" to update the
system packs. I haven't worked out exactly what a "letter
bump" entails for us right now.
* Separate issue: try not to be innovative about the Makefiles
you write by hand for sipb-athena source directories. I've
seen a few Makefiles from Yoav that do things like install
directly in /afs/.sipb.mit.edu/system/i386_nbsd1/usr/athena
instead of using /usr/athena, install with owner bin and
group bin, etc.. Changes like that should be applied
globally and with warning; they get in the way when applied
incrementally. I'd actually prefer Athena-style Imakefiles
(using /usr/athena/config, not the somewhat-Athena-like
templates in our /usr/X11/lib/X11/config) to hand-written
Makefiles until we have a better way to handle Athena source
tree management.
I'm trying to get our release process to be as close to the Athena
release process as is reasonable for private workstations. If any of
the above sounds wrong or too draconian, please comment on it; release
engineering is worthless if some of the developers don't buy into the
process. Hopefully I'll have better internal documentation on this
within a few months.