>
>Eric,
>
>Even though it may be a drastic move by causing some servers to crash
>due to the PUT PEERS NAMES command, *maybe* it will make these sites
>upgrade their LISTSERV to the current level.  Since it takes maybe
>a whole 5 minutes to upgrade to a new level, I see no reason why
>some sites are running a 1.5b LISTSERV!
>
>Darren
(* Excuse me while I put on my heat-resistant trenchcoat; I was going to
   say asbestos, but that's dangerous in and of itself. *)
 
Folks, I have an entirely different opinion to express.  First, we're
running 1.5i, so I'm not saying this as a recalcitrant installation.
I'm very, VERY concerned about the idea of DECIDING to crash a
service machine running at someone else's installation, without having
obtained permission to do so.  Yes, I realize the benefits to the rest
of us of having everyone at a good level of the package.  But the thought
of someone at another site deliberately introducing code into my system
that will cause a working piece of software to crash gives me LOTS of
concern.
 
Let's consider the realities of the situation for once, rather than
what we think *ought* to be done.  Many places have rules that limit
the frequency and timing of software upgrades.  I'm not terribly
burdened that way myself, but I can certainly understand the desire for
an installation to control when things change.  I won't remove
a working, yet obsolete version of a software product (even though
a more current version is available on my system) in the last week
of classes, for example, because someone might be using it.  I won't
put in a major set of maintenance to virtually ANYTHING during finals
week, just on the off chance that something might break in an unexpected
way and cause our students to have problems in the middle of finals.
So I can easily understand the desire of some places (and remember,
some of us are *miserably* understaffed) only to change their copy
of LISTSERV every so often.  Sure, installing a new version of LISTSERV
may take only 5 minutes.  But some of us feel the need to test it
before making it the production copy, rather than getting caught
with the bugs that invariably cause problems right after a new version.
(That's not a criticism of Eric; it's just a fact of programming life which
we're all afflicted with.)  And we may simply NOT HAVE THE TIME TO DO THAT!
Let's face it, LISTSERV is a nice, useful, important, (place your good
words here) package.  But it's probably not the most important piece of
software on your system; if I have to choose between upgrading a
(working, remember) version of LISTSERV or fixing a problem in (pick
your worst fireball here), I'm going to leave the working LISTSERV alone.
Eventually, I'll get to a point where LISTSERV gets the attention it
deserves, but right now, I've got alligators to fight.
 
I would not like to consider trying to explain to the director of my
center that someone outside of our site deliberately caused a piece
of working software to crash, just because we were downlevel.  That's
just the kind of activity and security nightmare that would cause some
people to giving serious thought to removing the product entirely,
and which could cause some people to start asking some legal questions.
I'm not entirely thrilled as it is with the idea of even the PEERS NAMES files
being automatically updated from outside.  Remember what happened a while back
when there were some problems with some of the entries and DISTRIBUTE
became so unreliable as to be totally unusable until we figured out that
CUNYVM's (or whosever) entry was wrong and needed to be changed?  I'm just
not entirely convinced that there's no other way of doing it.
 
In case you can't guess, I'm one of those who voted against allowing Eric
to automatically update the copy of LISTSERV running on our system, and
will do whatever it takes to disable such a feature if it appears.
 
Wouldn't simply removing the 1.4, 1.5b, etc. people from the PEERS NAMES
tables be just as good a solution?  (That implies that those people wouldn't
get the new PEERS NAMES, of course.)  Those old installations would be
left out of the LISTSERV network (i.e., no one would be DISTRIBUTEing to
them), any peers should still work (I think, not sure about this one),
non-peered lists would still work and DISTRIBUTE jobs from the downlevel people
would bounce back VERY quickly.
 
Since I doubt that most of the people running very old LISTSERVs are
heavily into DISTRIBUTE, it seems to me that would be a MUCH better
solution.  If he felt he had to, Eric could even send the downlevel people
a VERY truncated PEERS NAMES file (never to be updated again until you
heard from them that they had come up to a current level), which only
listed the downlevel set of people.  You'd end up with two disjoint
LISTSERV networks, but at least no one would be forcing another site's
LISTSERV to crash, just because their change control procedures wouldn't
let them upgrade LISTSERV as fast as Eric can put them out.
 
Please, flame back to me directly.  I've put a Reply-To back to me on this
note, but I don't know whether the list will respect it.
 
Richard