[383] in NetBSD-Development
Re: Problems with /afs/sipb/project/sipb-athena
daemon@ATHENA.MIT.EDU (jhawk@MIT.EDU)
Fri Jan 13 12:41:51 1995
From: jhawk@MIT.EDU
Date: Fri, 13 Jan 95 12:41:35 -0500
To: Greg Hudson <ghudson@MIT.EDU>
Cc: netbsd-dev@MIT.EDU, svalente@MIT.EDU
In-Reply-To: "[381] in NetBSD-Development"
[mh & zephyr fixed]
Great.
> I'm sure the other errors are as minor, but I don't want to spend a
> lot of time checking them out since I wasn't the person to put
> together those source trees. I might check on kerberos.
Agreed. As I said, I'm willing to go through them when I have
a free moment, but if their maintainers fix 'em, so much the better.
> (Actually, I am responsible for telnet. Does the installed
> /usr/athena/bin/telnet exhibit the same problem as the Athena telnet?
> If not, then something is odd, since I fairly recently built and
> installed telnet from the sipb-athena source tree.)
Yes it does. This is easiest seen with ``telnet ssa 25''...
[lack of athena->sipb version control/remembrance]
> The theory (as introduced by Sal)
Ah! Is this documented somewhere? It certainly oughta be, so that
some of us don't get confused, or remain ignorant :-)
> is that you copy over the source directory from the Athena release
> (except for kerberos, which came from the Cygnus source tree) and
> clear out all the RCS directories. Then, when you want to update
> the source, you can determine the relatively small number of changes
> that were made by looking for RCS files.
> A couple of packages probably came from lockers and not an Athena
> release, but that shouldn't affect the theory, since it's just a
> version difference.
I see two flaws with this, one significant, the other perhaps not:
major: This doesn't make clear where the source originates from.
For instance, I cannot tell where sipb-athena/telnet came from.
The telnet locker? The source "locker"? /afs/dev/source/src?
In the case of packages that have $Header$ tags, we still do not
know, as the RCS directories are cleaned out (doh!), but not all of
them have such... I would suggest we place a .wheretogetme (or equiv.)
file in the top level of each tree.
minor: Clearing out the RCS directories is, umm, well, one way
to do it. It may be convenient, but it means that it may still not
be clear what version a package came from, as the RCS tags
on the source files will be wiped out. Perhaps a better, but more
space-consuming solution, would be to:
Copy the source tree (including RCS directories)
Tag everything with an agreed-upon symbolic RCS tag, like
ATHENA_IMPORT
This would mean that we would not lose the original RCS information,
which I think is valuable.
Greg brings up the point that we're volunteers, and perhaps
shouldn't be expected to maintain working, clean, source trees.
I think that's nonsense, and that we're perfectly capable. *however*,
if what we need is a source tree grunge, I'm happy to be that grunge,
if it's truly necessary, but somehow I'd rather not...
--jhawk
