Newsgroups: news.software.b
Path: utzoo!utgpu!news-server.csri.toronto.edu!math.lsa.umich.edu!zaphod.mps.ohio-state.edu!rpi!rpi.edu!tale
From: tale@turing.cs.rpi.edu (David C Lawrence)
Subject: Re: Checkgroups problem
Message-ID: <AF0$2'-@rpi.edu>
Organization: Rensselaer Polytechnic Institute Computer Science, Troy NY
References: <1990Aug7.053447.19212@grian.cps.altadena.ca.us>
Date: 8 Aug 90 04:31:07 GMT
Lines: 121

   From: liz@grian.cps.altadena.ca.us (Liz Allen-Mitchell)
   Date: 7 Aug 90 05:34:47 GMT

   I ran the checkgroups message from Gene Spafford and got some interesting
   results.  Namely, it mentioned some groups including soc.culture.british
   as being ones I should remove!  Now soc.culture.british is a real group
   and is in the newsgroups file produced by checkgroups -- still, I was
   asked to remove it.  It wasn't the only one.

I don't really know why this is happening.  All I can say is that it
doesn't happen to me; anyway ...

   I'm running cnews dated 10-Jan-1990.  I don't know if that's the most
   recent or not.  I also can't find a manual entry for checkgroups...

It's not the most recent.  25 May 90 is.  I don't think it makes that
much difference though.  Geoff is currently working on a better
checkgroups; one thing that has inhibited him, as I understand it, is
that checkgroups behaviour isn't clearly defined.  Neither B News nor
C News does that hot a job of it.  You haven't found a manual page for
it partially because of it not being a command or something that
manual pages are generally written for (file formats, etc), and
partially because of the afforementioned reason of its ambiguity.  Of
course, things like "cancel" and "newgroup" are pretty well understood
by admins as to what they should do (ergo "clearly defined" by
default, even if there is the occasional battle which crops up
regarding propagation of cancels) and they don't have manual pages
either.  They are described in RFC 1036.  Unfortunately that document
isn't helpful with regard to checkgroups:

 3.7.  Checkgroups

     The message body is a list of "official" newsgroups and their
     description, one group per line.  They are compared against the list
     of active newsgroups on the current host.  The names of any obsolete
     or new newsgroups are mailed to the user "usenet" and descriptions
     of the new newsgroups are added to the help file used when posting
     news.

I have a few problems with the way C News does it, and I've been
meaning to write this for Geoff just to have some things to think
about (perhaps one or two here he didn't realise or didn't have any
admin input on).  The following comments all relate to C News checkgroups.

One is the way checkgroups mungs the newsgroups file, especially with
regard to the last sentence of the checkgroups description.  Arguably
the groups which checkgroups says to create will be created and then
they will indeed be new newsgroups so their descriptions should be in
the active file.  Sometimes (usually) though, for me, if the group
isn't there it isn't supposed to be.  Take the example of
comp.hypercube, which was renamed to comp.parallel.  Occasionally an
admin lets loose a large checkgroups on the net which includes that
old group.  I then have to edit out the line which was plunked into
newsgroups.  What I would like: include the descriptive line for the
group in the mail notification to the admin.  Then if I want to add
the group I can add the newsgroups description at the same time
without having to hunt for it in the checkgroups message.  (It would
also be nice if "addgroup" would take a line, either from stdin or the
command line, to add to newsgroups as the description.  I frequently
forget to do so when I make a new group.)

Next, I hate the way checkgroups always checks all groups, part of
which supposedly makes the hybridization of the message and the
localgroups and newsgroups files necessary.  If I want to do just a
bionet checkgroups, that's it.  Compare the bionet groups in the
message with the bionet groups in my active file.  Seemingly it should
do this by finding the hierarchies in the message, either by a new
leader line like !mod, a "checkgroups gnu bionet" type Control: header
or just by finding the ^[^.]*. top level names from the message.  This
last seems to have the drawback that I couldn't just "checkgroups
comp.sys" if that was all I was after.

checkgroups doesn't check moderated flags.  I wish it did.  In fact,
checkgroups doesn't care at all about flags.  I modified mine to
consider 'x'ed groups as not really there.  Ditto on = groups.
(Change the regexp which gets groups in active from
^([^.]*\.|general|junk|control) to ^([^.]*\.[ymn]$|general|junk|control)).)
This cuts down on telling me about groups that I don't really want to
hear about, like telling me to remove "alt.swedish.chef.bork.bork"
when I'm not really getting it anyway.  This is a problem, however,
when I have decided to x or = a group which does appear in the
checkgroups message.  I guess I like being reminded that I have it
this way, so I am encouraged to re-evaluate why I do, but what should
really be done (ignore it, allow a seperate exclusions file that says
"Yes, I want to x this group permanently and I don't want checkgroups
telling me about it everytime$&#*!", consider them present, whatever).
Because of not checking moderated groups, checkgroups can also make
bogus suggestions to "addgroup news.froup y" rather than "... m".

There is another problem that arises from the mixing of the gene pool
between the message and the *groups files.  Say I have a description
for a group but the checkgroups message has a different description
for the same group.  Not only do I now have two descriptions of the
group now in newsgroups, but I sometimes can't tell which one is the
newest one without going back to the checkgroups message or
newsgroups.bac to determine it.   I think that what I would like in
this case is just a tiny script that gets left in lib, and
notification in the message which says, "Descriptions changed for
these groups: ... Run /usenet/lib/update-desc to apply the changes."
update-desc (or whatever) could then even remove itself when it is
done. :-)

Since admins aren't always on nice window system machines when they
want to make some of the mods suggested by checkgroups, it would be
nice if it left the suggested changes in a file which could be sh'ed
or something.  A couple of quick edits to delete the changes not
wanted could be a lot less typing than typing all of the commands to a
shell or trying to extract them from a mail message (which might not
even be on the server to begin with -- mine aren't).  What goes hand
in hand with this, especially if checkgroups starts checking moderated
groups, is something that allows the admin to easily switch from a
moderate to a unmoderated group and vice versa -- perhaps even
addgroup not stopping because it found the group in active, but
instead changing its flag to whatever the new one is.  Right now when
I get something like the {rec,misc}.fitness thing showing up,
encouraging me to immediately start refiling rec to misc because of
the botch, I locknews and edit the active file.  I could also delgroup
and addgroup right back again.  Neither is as nice as just saying,
"change it."
--
   (setq mail '("tale@cs.rpi.edu" "tale@ai.mit.edu" "tale@rpitsmts.bitnet"))