kent@ssbell.UUCP (Kent Landfield) (05/24/89)
If you are *not* interested in archiving patches to posted software,
standardizing auxiliary headers for patches or extremely long
summaries, type 'n' now. You have been warned... :-)
The Week in Review - CALL FOR DISCUSSION - Creation Of comp.sources.patches
After a week of discussions on this topic I feel that it is time to
step back and review just what occurred in the past 8 days.
During the past week many ideas have been put forward. It is the
intent of this article to focus on the ideas presented in an attempt
to solve the problems with patches that currently exists on the
net. This is a discussion period and since I initiated this discussion
I feel that it is my responsibility to summarize the discussions
high points. I am not endorsing anything here unless specificially
stated. The material has been taken from articles recently posted and
are not the complete articles. I have tried my best not to misrepresent
anyone's comments. If I have have done so inadvertently, I am truely sorry.
Idea/Topic Overview
1. Creation of comp.sources.patches.
2. Problems with current use of comp.sources.bugs.
3. Alternate Newsgroup Creation ideas.
4. New auxiliary header to be used for patches only and
volume/issue filename suggestion for naming patches.
5. Current Versions list.
6. New USENET site, software kits and net software checklist.
7. Options to solve the problems.
** CREATION OF COMP.SOURCES.PATCHES **
kent@ssbell.UUCP (Kent Landfield)
# I am hereby initiating a CALL FOR DISCUSSION for the creation of
# the group comp.sources.patches. The intent of the newsgroup will be to
# distribute patches to software that has been posted to the sources and
# news groups. The comp.sources.patches newsgroup will be moderated although
# it would be an effective newsgroup even if it was not. According to the
# GUIDELINES FOR USENET GROUP CREATION the discussion is to last a minimum
# of two weeks and not more than thirty days. The CALL FOR DISCUSSION
# was begun Tue May 16 20:50:05 CDT 1989.
#
# For too long the net has had to accumulate its patches via "catch as
# catch can" methods. This is not acceptable. There are a large number of
# people who have spent many hours creating good quality software for the
# rest of us to use and enjoy. (Thank you, thank you, thank you.) It is not
# fair to them or to the rest of us to accept the software maintenance
# distribution procedures (or lack there of) that currently exist on the net.
# It is time we simplify the procedures by reducing the number of newsgroups
# that must be monitored for patches from 20+ to 1.
#
# It is time that the patches were archived just as effectively and completely
# as the original sources. There are many archive sites around the country that
# have complete sources archives. How many sites can say that they truely
# have a complete patches archive. I do not want to count the number of
# times I have asked someone for or had someone ask me for a patch to this
# or a that only to find out that no one in the area had it.
# comp.sources.patches would ease the work of many sysadmins. They would
# be able to reduce the number of newsgroups they read just to check for
# patches. The comp.sources.patches could be archived so that the community
# would be able to track and retrieve fixes much easier and quicker.
noel@ubbs-nh.MV.COM (Noel B. Del More Nashua)
# In summary, the advantages to posting patches to a moderated newsgroup
# are consistency of format, and absence of "chatter" in the newsgroup
# which in turn would allow archive sites to process these postings in a
# more efficient manner.
kent@ssbell.UUCP (Kent Landfield)
# It would also allow the community at large the ability to retrieve patches
# from the published archive sites. Currently its a matter of asking a
# neighbor or posting a request to the net.
#
# The patches are not tracked in such a manner that net
# users could determine the current patch level of any software posted
# to a sources group. It is a shame that I have to take the time to
# locate someone who has a patch that I missed just because I took a
# day off (seldom :-) ) while my "automatic sources archiver" is merrily
# storing the posted sources without human intervention.
paf@uts.amdahl.com (Paul A. Fronberg)
# 3. Where do you get some of the patches and distinguish between offical
# patches and ad hoc ones? Some are only available via ARPANET. How
# many times do we see "please send me patch #X for program Y". And
# how many times have we suddenly seen patch #4 and are missing #2 and
# #3. I don't know what the present status of the moderated source
# groups are and what the official patch policies are. I see on archive
# sites the moderated issued patches are included, but I don't know about
# the ones from comp.sources.bugs or other groups (haven't looked
# recently).
#
# 5. The chances of a patch being missed, lost, or corrupted is going to
# increase as the number of patches increase. If you miss one, you
# may not realize it for quite some time.
#
mhw@wittsend.LBP.HARRIS.COM (Michael H. Warfield (Mike))
# I agree totally with this. I am trying to establish a semi-automated
# source archive. One of my co-conspirators pointed out to me that I had
# to archive a pile of "discussion" groups in order to catch all the vital
# patches for the moderated source groups. AAAARRRRRRRGGGGGGGHHHHHHH!
# Now I have to weed through the discussions by hand to find the patches.
# I will vote for this group in a heart-beat as long as discussions are kept
# out of it - i.e. I agree that is should be moderated so only valid software
# patches end up their - no Re:'s.
** PROBLEMS WITH CURRENT USE OF COMP.SOURCES.BUGS **
woods@ncar.ucar.edu (Greg Woods)
# I thought that this is what comp.sources.bugs was for: bug reports and
# patches. The volume there is hardly overwhelming; why can't we just agree
# to post all the patches to programs that came out in comp.sources.* to
# comp.sources.bugs? I don't think a new group is needed; we already have
# one for this purpose.
kent@ssbell.UUCP (Kent Landfield)
# From my newsgroups file:
# comp.sources.bugs Bug reports, fixes, discussion for posted sources
#
# The problem with comp.sources.bugs as I see it is that it is there
# for *too many* purposes. There is too much discussion and chatter in
# the group for automatic archivers to be able to pick out the "diamonds
# and leave the coal".
#
# The patches that come through comp.sources.bugs do not have headers
# standardized so that archivers can save the patches consistently.
#
# I'll grant you that the volume in comp.sources.bugs is not overwelming
# but that is not the point. We need to be able to track the fixes to the
# sources just as effectively as we track the sources themselves. I can
# review an index of every package posted to comp.sources.unix by just
# reading an informational posting in the latest volume. (thanks rich)
# I can not do that for the patches. I for one think this is a major
# missing piece to the distribution and maintenance of sources on the net.
prc@erbe.se (Robert Claeson)
# The idea with comp.sources.patches is to have a moderated group where
# all official patches will appear so that we know that all the patches
# posted there won't break anything in the future. This can be a problem
# with all the official and unofficial patches that are posted to
# comp.sources.bugs.
ray@maxwell.physics.purdue.edu (Ray Moody)
# Comp.sources.patches would (presumably) be archived. Patches need to be
# archived, and neither comp.sources.bugs nor comp.sources.wanted is archived.
# Thus, there is a need for this group.
** ALTERNATE NEWSGROUP CREATION IDEAS **
prc@erbe.se (Robert Claeson)
# A bunch of comp.sources.unix.patch, comp.sources.misc.patch,
# comp.sources.x.patch etc groups would be even better than a
# single comp.sources.patches group, IMHO. That way, it would
# be much easier to track where the original source came from.
# For example, a source posting may appear in comp.sources.misc.
# A few weeks later, the same source but modified for X appears
# in comp.sources.x. After a while, it's time to send out a few
# patches. If the posting had the same name in both sources groups,
# it can cause a lot of confusion if there's only a single group
# for patches that is shared among the different sources groups.
noel@ubbs-nh.MV.COM (Noel B. Del More Nashua)
# And it would also be nice if their was a companion "patch" newsgroup for
# each of the newsgroups to which sources are posted, eg.
# "comp.sources.unix.p" or something similar.
In article <479@ssbell.UUCP> kent@ssbell.UUCP (ssbell Admin) writes:
# This is probably overkill in that it would (if moderated groups) require
# eight different moderators as the sources groups currently stand. There is
# not enough patches traffic to really justify a patch newsgroup for each
# sources group.
dal@midgard.Midgard.MN.ORG (Dale Schumacher)
# I agree that creating multiple patch groups at this time may not be the
# best idea, however, a small name change would allow more flexibility in
# future naming. If the "comp.sources.patches" group was instead called
# "comp.patches", it would open the door for a future "comp.patches.*"
# tree which would properly parallel "comp.sources.*", "comp.sys.*", etc..
** NEW AUXILIARY HEADER TO BE USED FOR PATCHES ONLY **
rsalz@bbn.com (Rich Salz)
# The issue/volume structure works for lots of things, but is bad for
# handling source/patch references. When reading index lists, you have
# to be REAL CAREFUL about reading everything, looking for patches.
# Putting an annotation in the lists that "has since been patched XX times"
# is a good idea.
#
# Patches have long been problematic, mostly for mod.sources-
# comp.sources.unix postings. Some sites (such as the archives
# I maintain on UUNET) quietly put the patch files into the original posting
# directory, but this loses badly for those with strong senses of history
# and/or those who archive by issue/volume number (e.g., Purdue).
#
# You need a way for the random downloader to get the original posting
# and all the patches.
kent@ssbell.UUCP (Kent Landfield)
# How about this ? Below is a sample of the auxiliary headers for the
# initially posted article. The first example is the normal way they
# are done today. The second example is for a patch that is about to
# be posted. Note the addition of a reverse reference line that points
# back to the initially posted article or set of articles. In the event
# of multiple initially posted parts, the reverse reference is to the
# first part that was posted.
#
# Auxiliary Headers For Initial Postings:
#
# Submitted-by: Kent Landfield <kent@ssbell.UUCP>
# Posting-number: Volume 22, Issue 122
# Archive-name: archive/part01
#
# Auxiliary Headers For Patch Postings:
#
# Submitted-by: Kent Landfield <kent@ssbell.UUCP>
# Posting-number: Volume 23, Issue 14
# Patch-To: Volume 22, Issue 122
# Archive-name: archive/patch1
#
# Now just what does this buy us ? Well archivers can be modified that will
# understand that the Patch-To: line indicates the article is a patch.
# For Volume/Issue archiving, the article would be stored as volume23/v23i014
# where as for Archive-Name archiving the archiver now has enough information
# to put the article into the "correct" place (volume22/archive/patch1) in the
# archive. After the article has been stored, the archiver should then log the
# fact that a patch was posted into a "Current Versions Log".
#
# If you use the method that was described for the Archive-Name method
# above, a random downloader is not needed. It is only needed for the
# Volume/Issue method. The random downloader could get the base article(s)
# from the archives and then scan the Current Versions Log for the location
# of the subsequent patches. No massive searches necessary.
noel@ubbs-nh.MV.COM (Noel B. Del More Nashua)
# What would be nice would be to use the original volume name of the
# posted program with the patch level appended to it, eg. v18015-p1,
# although any standard catologing scheme would do just as well.
** CURRENT VERSIONS LIST **
kent@ssbell.UUCP (Kent Landfield)
# What would be of use, is a listing of the current verions of each of the
# major packages. In this way, I could easily determine if a software package
# that I am running on ssbell needed to be upgraded. This could be a monthly
# posting to the just proposed comp.sources.patches newsgroup.
#
# I for one think this is a major
# missing piece to the distribution and maintenance of sources on the net.
mbeast@tls.UUCP (Michael East)
# I believe that this alone (the summary of current versions) would be
# well worth the effort. I for one stuff interesting sources away for
# that rainy day when I can implement them and sometimes find that a few
# months have elapsed since the posting. Keeping track of the fixes for
# these various sources just seems to push that rainy day further into
# the future!
#
# Also, after successfully running a package for a time, it would be
# nice to see what the current version is on the net. I tend to ignore
# fixes when the package is running smoothly (I know, I know - silly me!;-),
# thus finding that I am three or four versions behind when the Bug
# finally surfaces and I have to fix it in a hurry!
paf@uts.amdahl.com (Paul A. Fronberg)
# Another suggestion is to
# include the current patch level with the periodic index postings
# for comp.sources and comp.sources.misc.
rsalz@bbn.com (Rich Salz)
# Putting an annotation in the lists that "has since been patched XX times"
# is a good idea.
#
# I'm working on providing an EXHAUSTIVE index for c.s.u, which includes
# forward references to patches, but it's a lot of work (and I don't have a
# BBN charge number for it :-).
kent@ssbell.UUCP (Kent Landfield)
# This will be a major step in the right direction !!! Thanks in advance!
** NEW USENET SITES, SOFTWARE KITS AND NET SOFTWARE CHECKLIST **
paf@uts.amdahl.com (Paul A. Fronberg)
# Perhaps some sort of "kit" with the commonly requested programs could
# be send out once every few months? 1 megabyte or so a year would probably be
# sufficient. My canidates would be news, patch, uudecode/encode, arc (or
# equivilant), binhex, shar. In short the programs necessary to access and
# extract news programs/articles.
hans@nlgvax.UUCP (Hans Zuidam)
# Some sort of "kit" would be *really* usefull. It would allow a new site
# to be up and running with the correct software in no time. However, posting
# such a kit every x months would be a gross waste of bandwidth assuming that
# most sites are running the correct software.
#
# When I was a (sort of) system manager at another site a couple of years
# ago it was a hell of a problem just to get started. I did not know if I
# had the correct software, saw people talking about patches I did not have,
# didn't know if I needed them and so on. When you start with a Usenet
# connection you generally do not even know what you *do* need. If you
# help a new site to get online you have to dig software from all corners
# of your filesystems ;-) and forget half. This takes a lot of time for both
# parties involved.
kent@ssbell.UUCP (Kent Landfield)
# I totally agree. A kit does need to be created. The kit list could be a
# list of all the software that should be distributed to each new site on
# the net. The new site would receive the kit list and the associated software
# from the site that it was connecting to. My objection is to having the
# software designated on the kit list transmitted through everyone's sites.
#
# The software associated with the kit list is already available on most
# sites. If a kit list was created, the admins of the sites helping a new
# site "connect to the net" could use the kit list as a checklist to assure
# that the new site has all the "standard tools".
** OPTIONS TO SOLVE THE PROBLEMS **
stacy@mcl.UUCP (Stacy L. Millions)
# Right, so as I see it we have 4 options:
#
# 1. Leave things the way they are. No, I don't think this is a good
# option, just *an* option.
#
# 2. Create a new moderated group for patches. (Like what we are
# discusing now :-)
#
# 3. Moderate comp.sources.bugs. The moderator would make sure that
# the patches have an "Archive-name:" in them for easy automation
# of the archiving. This would also encourage people to use
# comp.sources.d for discussions and leave comp.sources.bugs for
# *bugs* (what a novel idea :-).
#
# 4. Posting _official_ patches back through the moderated group where
# the sources came from. This one is liable to get me lynched.
# The moderators have enough work already, and most people would
# like to see a fast turn around on patches, so I don't think
# increasing the work load of the existing moderators would be such
# a good idea. It is just a consideration.
#
So where are we here and what have we accomplished during the last week
of discussions ?
There is now a focus on a problem that need not exist. We should not
be seeing "Official" patches coming into comp.sources.bugs.
There seems to be a split about the usefulness of the proposed
comp.sources.patches. There are those, myself included, who are *totally*
frustrated with the current situation and want comp.sources.patches
created in hopes that it will be a step towards increased tracking
and availability of patches from published archive sites.
Is comp.sources.patches the BEST answer to the problem, probably not.
That is why we are discussing it here, right :-)
Sources should be posted to the newsgroup in which the source was
initially posted. To all the authors of posted source that follow
this procedure, THANK YOU, THANK YOU, THANK YOU. To all other authors
that do not follow this procedure, PLEASE DO!!!
Is the added work going to be too much of a burden on the existing
moderators ? I cannot tell, maybe they can. One possible soulution
was hinted at in personal mail from Greg Woods. Each sources group
could have multiple moderators.
With multiple moderators, there could be one for normal sources and
then one for tracking patches. The patches would still be sent back
to the normal sources moderator to assign the volume/issue number and
do the actual posting. The testing, tracking and patch posting format
verification would be done by the patches moderator. In this manner
the current moderator's work might actually be lessened slightly
and there would already be a backup moderator in place in the event
the initial moderator wished to take a vacation :-) (They do that sometimes
ya know.. :-)) I am not trying to step on any toes. This is a discussion
period and I am just throwing out ideas.
# If you have ideas, post them. For the time being, read comp.sources.bugs.
# /rich $alz
-Kent+
----
Kent Landfield UUCP: kent@ssbell
Sterling Software FSG/IMD INTERNET: kent%ssbell@uunet.uu.net
1404 Ft. Crook Rd. South Phone: (402) 291-8300
Bellevue, NE. 68005-2969 FAX: (402) 291-4362