noel@ubbs-nh.MV.COM (Noel B. Del More Nashua) (05/16/89)
In article <bahx024m26XB01@amdahl.uts.amdahl.com> paf@uts.amdahl.com (Paul A. Fronberg) writes: > >One is that the patches may not be posted in a commonly read newsgroup. Quite true, and a royal pain as well! >I claim that all offical patches should be issued through the moderated source >group that the program was originally posted. This would allow easier >administration of fixes and put them in a known group. This is an idea that has alot of merit. While it would result in some inconvienence, in that the patch would have to pass through the moderator resulting in some delay reaching the end user of the program, it would introduce some degree of consistency into the posting of patches. 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. 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. I would have suggested that "official" patches be posted to the same newsgroup as to which the original was posted but that might not be possible, wise or too much of an additional burden on the moderators of these groups. 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. The disadvantages are increased time for the posting to reach the end user. I'm sure that others will point out other advantages and/or disadvantages, but what do you expect on only one cup of coffee. B-) I'd be interested in hearing what others have to say about the subject, is the idea worth further investigation and possible call for discussion. >The second problem is that with certain critical programs (news, patch) it >probably makes sense, at some point, to do a repost with all the patches >applied. > >Perhaps certain programs should be periodically posted once a quarter or once a >year just to ensure that the community has up to date versions. With the above approach, it would probably not be necessary to repost "critical" programs except for major upgrades and new releases. Noel -- Noel B. Del More | decvax!ubbs-nh!noel 17 Meredith Drive | noel@ubbs-nh.mv.com Nashua, New Hampshire 03063 | It's unix me son! `taint spozed tah make cents
kent@ssbell.UUCP (Kent Landfield) (05/18/89)
In article <340@ubbs-nh.MV.COM> noel@ubbs-nh.MV.COM (Noel B. Del More Nashua) writes: >In article <bahx024m26XB01@amdahl.uts.amdahl.com> paf@uts.amdahl.com (Paul A. Fronberg) writes: >> >>One is that the patches may not be posted in a commonly read newsgroup. > >Quite true, and a royal pain as well! > >>I claim that all offical patches should be issued through the moderated source >>group that the program was originally posted. This would allow easier >>administration of fixes and put them in a known group. > >This is an idea that has alot of merit. While it would result in some >inconvienence, in that the patch would have to pass through the >moderator resulting in some delay reaching the end user of the program, >it would introduce some degree of consistency into the posting of >patches. It would also introduce the ability to archive the patches instead of having to hunt for them or post requests to the net only to have your spool directory swamped by the many good people that respond by sending the requested patch. >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. 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. >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. 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 disadvantages are increased time for the posting to reach the end >user. This is true of any source related/moderated group. I would *not* like to see comp.sources.unix become unmoderated just to get the sources to me faster. The moderators play an important role of increasing the quality and consistency of postings. >I'd be interested in hearing what others have to say about the subject, >is the idea worth further investigation and possible call for >discussion. A Call for Discussion has already been initiated by myself for the creation of the newsgroup comp.sources.patches. Judging by my mailbox, I am not the only one who feels that the current "all over the place" posting of patches is unacceptable. -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
ben@val.UUCP (Ben Thornton) (05/18/89)
Speaking of patches, would someone please post the most recent version of patch? I have been running on an old version. Thanks. -- Ben Thornton packet: WD5HLS @ KB5PM Video Associates Labs uucp: ...!cs.utexas.edu!oakhill!val!ben Austin, TX fidonet: 1:382/40 - The Antenna Farm BBS
dal@midgard.Midgard.MN.ORG (Dale Schumacher) (05/19/89)
In article <479@ssbell.UUCP> kent@ssbell.UUCP (ssbell Admin) writes: |In article <340@ubbs-nh.MV.COM> noel@ubbs-nh.MV.COM (Noel B. Del More Nashua) writes: |>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. | |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. 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..
lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) (05/19/89)
In article <340@ubbs-nh.MV.COM> noel@ubbs-nh.MV.COM (Noel B. Del More Nashua) writes: >I would have suggested that "official" patches be posted to the same >newsgroup as to which the original was posted but that might not be >possible, wise or too much of an additional burden on the moderators of >these groups. The current setup used by comp.sources.{unix,misc,games,x} is to include a header in the message body of the format PRODUCT/PART#. Most existing automated source archivers seek out this information and use it to build the pathnames in the archive tree. The moderators are responsible to see that the PRODUCT part of the header is unique across all posted software packages within their group. The PART# part of this header consists of (usually) the string "Part##" with ## replaced by a numerically ascending sequence of numbers. If the Part## string were replaced by Patch## for postings of patches, the existing archiving software would automatically tuck the patches away for safe keeping right along side of the corresponding source. No muss, no fuss. This also solves a potential conflict between package names if we were to use a single common patch group. What if Rich Salz and Brandon Allbery post seperate packages to their respective groups, each called "foo?" We would need to include group information in patch postings in addition to the other info. By posting patches via the original group, possible name space collision is avoided. One problem with this idea is the delay in getting things "out the door." I don't perceive this to be as big of a problem as some people think, as I'm sure the moderators would give priority to patches over original source (primarily based on the assumption that patches are smaller than source postings :-) -- Lyndon Nerenberg / Computing Services / Athabasca University {alberta,decwrl,ncc}!atha!lyndon || lyndon@cs.AthabascaU.CA
jv@mh.nl (Johan Vromans) (05/21/89)
In article <591@aurora.AthabascaU.CA> lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) writes: > The current setup used by comp.sources.{unix,misc,games,x} is to include > a header in the message body of the format PRODUCT/PART#. Most existing ^^^^^^^ I think it's necessary to include the version number, e.g. elm2.2/part## . Makes it possible to archive different versions of a product. -- Johan Vromans jv@mh.nl via european backbone (mcvax) Multihouse Automatisering bv uucp: ..!{mcvax,hp4nl}!mh.nl!jv Doesburgweg 7 phone: +31 1820 62944 2803 PL Gouda - The Netherlands fax: +31 1820 62500
allbery@ncoast.ORG (Brandon S. Allbery) (05/23/89)
As quoted from <340@ubbs-nh.MV.COM> by noel@ubbs-nh.MV.COM (Noel B. Del More Nashua): +--------------- | In article <bahx024m26XB01@amdahl.uts.amdahl.com> paf@uts.amdahl.com (Paul A. Fronberg) writes: | >I claim that all offical patches should be issued through the moderated source | >group that the program was originally posted. This would allow easier | >administration of fixes and put them in a known group. | | This is an idea that has alot of merit. While it would result in some | inconvienence, in that the patch would have to pass through the | moderator resulting in some delay reaching the end user of the program, | it would introduce some degree of consistency into the posting of | patches. +--------------- Bill Randle (comp.sources.games) and I already do this *if we are sent the patches*. I'm not certain about Rich Salz and comp.sources.unix; but we can't post what we haven't been sent by the author of the original package. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
meissner@tiktok.dg.com (Michael Meissner) (05/23/89)
In article <963@midgard.Midgard.MN.ORG> dal@midgard.Midgard.MN.ORG (Dale Schumacher) writes: | In article <479@ssbell.UUCP> kent@ssbell.UUCP (ssbell Admin) writes: | |In article <340@ubbs-nh.MV.COM> noel@ubbs-nh.MV.COM (Noel B. Del More Nashua) writes: | |>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. | | | |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. | | 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.. | I'm of the opinion that we should create NO new news groups for patches. Before you ready the hot pitch and tar, let me explain. Yes, comp.sources.bugs is clearly inadequate. I beleive that offical patches should go through the same group that posted the package in the first place. If that is the case, I think that moderators should post patches ASAP, ahead of the normal queue of postings. I'm also of the opinion that, even though the volume the package may be closed for new postings, the patches should have the appropriate headers so that they get archived in the SAME directory the patch is in. This way, when people grab packages with FTP, UUCP, or mail based servers, they don't have to go looking at later directories for the patches. Comp.sources.x is the closest to the approach I mentioned. While I'm at it, comp.sources.x does another thing I wish the other groups would do: Even if a package consists of a single source, it should go in a directory by itself. That way if/when a patch comes, you have a location to store it in. -- Michael Meissner, Data General. Uucp: ...!mcnc!rti!xyzzy!meissner If compiles were much Internet: meissner@dg-rtp.DG.COM faster, when would we Old Internet: meissner%dg-rtp.DG.COM@relay.cs.net have time for netnews?
lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) (05/24/89)
In article <JV.89May20215744@mhres.mh.nl> Johan Vromans <jv@mh.nl> writes: >I think it's necessary to include the version number, e.g. >elm2.2/part## . Makes it possible to archive different versions of a >product. If you look at the naming scheme used in comp.sources.unix you will find that Rich is already doing this, although this is one thing there isn't currently a standard for. Maybe there should be? -- Lyndon Nerenberg / Computing Services / Athabasca University {alberta,decwrl,ncc}!atha!lyndon || lyndon@cs.AthabascaU.CA