[net.news.group] Dealing with reorganization

stewart@harpo.UUCP (stewart wiener) (02/28/84)

Chuqui's proposed reorganization of newsgroups into more of a tree structure 
is very worthwhile.  It will have to be done eventually, and I think we should
start making plans now.

There may be large problems with the following outline, but it can serve at
least as a thought-experiment:

1.  Nail down what newsgroups will go where.  New umbrella groups might 
    include net.sci, and net.cs.  (And how about net.sf, with .startrek, 
    .drwho, and .sw subgroups?)  

    We could argue details forever -- someone will eventually have to decide.  
    I'd nominate cbosgd!mark.  And/or an organized (!!) committee of interested
    newsusers.  Anarchy accomplishes very little.  Look at net.records.  NOBODY
    has protested nuking it, LOTS of people said do it, and HERE it still is.
    This is a separate issue, I guess, but LET'S ORGANIZE, putting ultimate
    authority in the hands of somebody we all trust not to abuse it.  (Without,
    I should add, taking anyone else's privileges away.)

2.  Contact every news administrator at every site we can.  By US Mail or phone
    if need be.  We need their active cooperation in order to have a smooth
    transition.

3a. Distribute new news software able to handle a 'rename' command.  Lots of
    rewriting, lots of problems.  A simpler alternative might be:

3b. On a given date, say October 1, several backbone sites simultaneously
    send out newgroup messages.  (To reduce propagation delay.)  Needless to
    say, net.announce will keep everyone posted.

    News administrators are given 7-10 days to move existing articles to the
    appropriate new locations, most of them using a centrally supplied shell
    script and/or C program.  After a deadline, the same backbones send out
    the rmgroup messages.

There will be shakedown problems -- some users will miss articles, or see them
twice; some will post to the wrong places; some sites will recreate defunct
groups.  A few misplaced articles will be killed by the rmgroup.  All this
will go away in a number of weeks, and we'll be left with a more efficient,
streamlined, and easy-to-read Usenet.  And we'll have an organization better
able to deal with further restructuring problems.

Oh boy will I ever get flamed for this.  But think about it carefully first.

--
	  Stewart Wiener		  :-)  "Read and weep as did 
              ******           	    	  :-)   Alexander when he beheld
  {allegra,decvax}!harpo!stewart          :-)   the glories of Egypt."

steveb@shark.UUCP (02/29/84)

reorganization of the news structure (and further agree that the
newsgroup structure must become more treelike).  It seems impossible to 
do it in any other way than the suggested "flag day" of netwide changes.
	One question to discuss:  Should this flag day include new 
software as well, or only new group structures within the current 
news software?  Under the current software, there is no EASY way to
subscribe to net.a and also net.a.q, while at the same time NOT
subscribing to net.a.r, net.a.s, etc.
	What are the initial suggestions for the top level groups?

fair@dual.UUCP (Erik E. Fair) (03/01/84)

In fact, a concerted `newgroup' by the backbones, will work, if they all
do one other thing. The `sys' files can support !group, so that group
does not get passed on.

The exact structure of the new heirarchy can be argued in this newsgroup,
where all such arguments are typically. Adam Buchsbaum has been a kind of
recording secretary for this sort of thing for quite some time now,
(Thank you, Adam!) and I don't see how this reorganization will create
more than the usual level of flaming (Oddly enough though, this is one
of the rare times I feel compelled to post my $.02 in net.news.group),
so he can probably handle it. (S'ok with you, Adam?)

	Erik E. Fair

	dual!fair@BERKELEY.ARPA
	{ihnp4,ucbvax,cbosgd,decwrl,amd70,fortune,zehntel}!dual!fair
	Dual Systems Corporation, Berkeley, California

Pucc-H:Physics:suitti@CS-Mordred.UUCP (03/03/84)

Why not do it slowly, using the present system.  There is little need
to screw things up further with new software.

1). decide on the new structure, and what goes where.
2). send out the group creations.
3). send out notices in the groups affected, and in "announce", or whatever
	as to what's going on.
4). wait, say, a month for trafic to stop in the old versions of the
	groups.
5). send out the rmgroups.

	This need not be done all at once.


Stephen Uitti (Purdue physics site manager)
UUCP:		pur-ee!Physics:suitti, purdue!Physics:suitti
INTERNET:	suitti @ pur-phy.UUCP