[6983] in SIPB bug reports
Re: wish, exmh, etc.
daemon@ATHENA.MIT.EDU (John Hawkinson)
Wed Aug 26 09:51:18 1998
To: Salvatore Valente <svalente@MIT.EDU>
Cc: bug-sipb@MIT.EDU, bug-tcl@MIT.EDU
In-Reply-To: Your message of "Wed, 26 Aug 1998 04:40:35 EDT."
<199808260840.EAA16242@StarbaseZero.ne.mediaone.net>
Date: Wed, 26 Aug 1998 09:51:07 EDT
From: John Hawkinson <jhawk@MIT.EDU>
I have some issues with definitions, and so forth.
I've been hoping this thread would resolve itself in a reasonable
way, and I'm at ietf with constrained man-bandwidth, so I've been
not contributing. More's the pity.
It seems inappropraite that but-tcl is not on the cc list of this discussion.
Added.
>As the Czar of the sipb locker,
I object to that characterization :-)
>I'll throw in my two cents: wish should remain in the tcl locker and
>exmh should remain in the sipb locker.
Assuming the tcl locker is maintained and replicated, that seems reasonable.
If it is not maintained and replicated, I don't think it is.
>All this silliness started when jhawk wrote:
>
> It's a bug for anything in the sipb locker to depend on the
> tcl locker, which is unmaintained (!) and unreplicated.
>
>And Jacob replied:
>
> I am willing to install tcl/tk in the sipb locker, if quota space
> can be found.
>
>I can't think of any good reason for tcl to be installed in the Sipb
>locker. Certainly, it's a great idea for some Sipb member(s) to offer
>at least the same level of support for tcl as is offered for software
>in the sipb locker. However, putting tcl in a separate locker makes
>life a little easier for both the people who maintain tcl (should such
>people exist) and the people who maintain other software in the sipb
>locker.
I would go further and say that putting tcl into seperate per-version
lockers makes life easier for both the tcl maintainers and the people
who use tcl. Of course, the tcl locker could still exist and point
to a version-specific locker.
c.f. /afs/sipb/project/tcl{76,80}, and the logic that the creation
of that was associated with, possibly only documented to sipb-afsreq,
but probably to bug-tcl.
>And it may make life a little easier for the people who want to use
>tcl on Athena. (If you didn't know where to find tcl on Athena,
>would you be more likely to look for it in the "sipb" locker or the
>"tcl" locker?)
I don't think this is a strong reason by itself, but sure, it seems
reasonable.
>As for the idea that it's a bug for exmh to be in the sipb locker
>while there's no maintained version of tcl on Athena: No, that's not a
>bug. A bug is something that keeps you from fully using the software.
>("exmh doesn't work in the following way...")
You are free to stipulate that that is your definition of bug.
As the person who introduced the term into the discussion, I assert
that my definition of bug is a suboptimality that makes a software product
harder to use, or causes it to fail some requirements. For Supported software
on athena, in general, those requirements include having all dependant
pieces be supported, and be replicated. Obviously this is violated not
infrequently, but I still consider them bugs.
In further places where this distinction is unclear, I encourage you to
use bug[svalente] and bug[jhawk] notation to make it clear what sort of
bug you refer to. If you'd prefer other labels, that's fine as long
as you define them.
>Granted, I don't think any new tcl software should be installed in
>the sipb locker while the tcl locker is unmaintained, but a lot of
>people depend on exmh to be there, and Jacob is doing a fine job of
>keeping it working, so I don't see any cause for alarm right now.
I think the degree of support in the tcl locker is sufficiently bad that
there is some cause for alarm (lets call it PTL), and we should make sure
it gets fixed some time in, say, this calendar year.
>In other news, a couple of people mentioned the possibility of moving
>exmh to the tcl locker and putting a symlink in the sipb locker.
>However, nobody has offered even a weak argument why this would be
>a good idea. It sure sounds like a waste of time to me.
I don't think there's a compelling reason.
>In still other news, Chad mentioned:
>
> At the time, the idea was to keep the stable tcl in sipb and the
> latest in tcl...
>
>As a generic Athena user, I'd expect to find a stable tcl installation
>in a locker called "tcl", and a bleeding edge version (if one exists)
>in a locker called something like "tcldev". That seems to be
>more-or-less the precedent with other large systems on Athena.
Yeah, and it's usually a system that works pretty poorly and is awfully
confusing to users and developers alike, and we should stamp it out
like the lying-on-the-floor-and-dusty-rug that it is.
My "requirements" are clear: maintain and replicate tcl. In the tcl
locker or in the sipb locker or in the exmh locker, it doesn't
really matter.
--jhawk
