kent@ssbell.UUCP (Kent Landfield) (05/21/89)
In article <31559@sri-unix.SRI.COM# rsalz@bbn.com (Rich Salz) writes:
# 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.
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".
Or if the archiver uses links to allow for "multiple views" of the archives ...
# This is the easiest one to answer :-) "we" do nothing about it. The
# author of the program gets to draw the line. Yes, it is a pain sometimes
# to be at perl2.37 as opposed to perl3.
Yes! This is the responsibility of the author/maintainer. It is not a
moderator problem. If you have beefs here, mail to the author. Most
authors love to get "constructive ideas". Flames get you nowhere.
# 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).
The volume/issue archiving is more prevalent than many think...
# You need a way for the random downloader to get the original posting
# and all the patches.
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.
# 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 :-).
This will be a major step in the right direction !!! Thanks in advance!
# I think that patches somehow have to be worked into the current groups --
If the current problems with patches can be overcome, I could agree
with you. But.. someone, somewhere missed the patches posted to
comp.sources.bugs today...
# If you have ideas, post them. For the time being, read comp.sources.bugs.
# /rich $alz
Ditto!
-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