[57] in DCNS Development
Filesystem Reorganization for release 7.3
daemon@ATHENA.MIT.EDU (Jonathan I. Kamens)
Mon Jul 8 14:33:04 1991
Date: Mon, 8 Jul 91 11:29:32 -0700
From: "Jonathan I. Kamens" <jik@cats.UCSC.EDU>
To: akajerry@ATHENA.MIT.EDU
Cc: jon@MIT.EDU, dks@MIT.EDU, Raeburn@MIT.EDU.akajerry@ATHENA.MIT.EDU,
In-Reply-To: akajerry@ATHENA.MIT.EDU's message of Mon, 8 Jul 91 14:25:20 -0400 <9107081825.AA16924@ix>
From: akajerry@ATHENA.MIT.EDU
Date: Mon, 8 Jul 91 14:25:20 -0400
I can't think of any real justification SIPB can give for
being treated as anything other than a third party software
provider/distributer and still be allowed complete control over the
contents of the SIPB locker.
"Backward compatibility."
If you want to take the /usr/sipb link away, after letting it stay for
years, fine. But you'll have to give us time to recompile everything
in the sipb locker that relies on /usr/sipb, and you'll have to give
user services notice far in advance so that all of the documentation
that refers to /usr/sipb can be changed, and so that consultants are
prepared when people start reporting that their account will no longer
let them run sipb programs.
In other words, taking the link away for 7.3 would not be fair.
Taking it away for 7.4, if you tell us know that you're going to do
it, might be reasonable.
jik
