[3021] in SIPB bug reports
gnuserv not installed properly in sipbsrc
daemon@ATHENA.MIT.EDU (Jonathan I. Kamens)
Wed Jul 8 23:39:58 1992
Date: Wed, 8 Jul 92 23:39:12 -0400
From: "Jonathan I. Kamens" <jik@pit-manager.MIT.EDU>
To: ckclark@MIT.EDU
Cc: bug-sipb@Athena.MIT.EDU
In-Reply-To: Calvin Clark's message of Wed, 8 Jul 92 20:27:46 EDT <9207090027.AA16810@deathtongue.MIT.EDU>
Date: Wed, 8 Jul 92 20:27:46 EDT
From: Calvin Clark <ckclark@MIT.EDU>
References: <9207082331.AA16756@deathtongue.MIT.EDU>
<9207082334.AA19740@pit-manager.MIT.EDU>
Reply-To: ckclark@MIT.EDU
I should think that sipbsrc would get pretty big if we decided on that
goal.
I don't see why "deciding" on anything should be an issue, since that
has been the policy, as far as I know, for as long as I've been
working on the sipbsrc locker. And I've been working on it for quite
a bit longer than you, so I'm in a better position to know :-).
Seriously, yes, sipbsrc would get pretty big, but it already *is*
pretty big, and we *have* the disk space. Disk space is a lot cheaper
than having to tell users who send in bug reports saying, "Program <x>
dumped core, the core file is in file <y>," and not being able to do
anything about it because we don't have unstripped binaries and
building the program again results in a binary that doesn't match the
core file.
This *does* happen. People in the SIPB tend to develop programs, not
just install them. And even when we install something from the net,
if it coredumps we tend to try to track down the problem before send a
bug report to the real maintainer. We can't do that if there aren't
object files.
It seems that from looking at the number of build trees under
rsaix in comparison to those under vax that this precedent, if it ever
existed, has not exactly been followed of late.
I'm not sure what you mean. I ran the script ~jik/tmp/check-objs.pl,
which produced the output in ~jik/tmp/check.out. According to it, the
following percentages of build trees in the various architecture
directories have object files:
vax 64%
rt 88%
decmips 72%
rsaix 82%
sun4 96%
NeXT 96%
TOTAL 79%
It seems to me that the majority of build directories *do* have object
files.
There are many things that would be nice in the sipb locker. It would
be nice if the whole thing could be built from a top-level
Imakefile/Makefile, like the Athena source tree.
It is difficult to do this. I *almost* had the sipb locker doing this
a couple of years back, but I didn't have the time to keep it going,
and since then, things have gotten very out of sync. It is not an
easy problem.
It would be nice if
everyone updated FILES.look when installing new programs, etc.
FILES and FILES.look are updated automatically every night.
I don't see any POLICY file in the sipbsrc locker. Maybe there should
be one.
Yes, probably.
I don't think you should write it. I don't think I should
write it. I think it should be written by those who are likely to be
maintaining the sipb locker next year, the year after that, and the year
after that. Maybe some of us fogies can give some advice, but it better
be short and to the point, otherwise no one's going to remember all of
it (which is one reason why it should be written down.)
I think the "fogies" better do more than "give some advice," or things
are going to be forgotten. It seems quite reasonable for the people
who are going to be doing the maintenance to decide on the final
policy, but it also seems to me like the initial drafts of the policy
document should be written by the people who are doing the maintenance
now.
No, I take that back. I don't have time to do it. I am, however,
willing to read over a policy document written by someone else and
comment on what I think is missing. Alternatively, I am willing to
sit down with someone who is interested in this and discuss, orally,
what I think all of the policies and procedures are, or at least the
polices and hints that I use when maintaining sipbsrc.
jik
