Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!xanth!mcnc!rti!xyzzy!tiktok!meissner From: meissner@tiktok.dg.com (Michael Meissner) Newsgroups: news.groups,comp.sources.d Subject: Re: Posting Patches; Was Patch frequency Keywords: Patches, News Message-ID: <6368@xyzzy.UUCP> Date: 23 May 89 15:36:40 GMT References: <340@ubbs-nh.MV.COM> <479@ssbell.UUCP> <963@midgard.Midgard.MN.ORG> Sender: usenet@xyzzy.UUCP Reply-To: meissner@tiktok.UUCP (Michael Meissner) Followup-To: news.groups Organization: Data General (Languages @ Research Triangle Park, NC.) Lines: 40 Xref: utzoo news.groups:9749 comp.sources.d:3681 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?