From owner-freebsd-current Sat Apr 8 15:12:33 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA27538 for current-outgoing; Sat, 8 Apr 1995 15:12:33 -0700 Received: from dataplex.net (SHARK.DATAPLEX.NET [199.183.109.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id PAA27532 for ; Sat, 8 Apr 1995 15:12:25 -0700 Received: from [199.183.109.242] by dataplex.net with SMTP (MailShare 1.0b8); Sat, 8 Apr 1995 17:12:20 -0500 X-Sender: wacky@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 8 Apr 1995 17:12:24 -0500 To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: closing bin/295 Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >As Richard Wackerbarth wrote: >> >> >No. It should only refer to the version that fixes the problem. >> >Interested parties can check the CVS log for this. We've already been >> >discussing this topic, and it's been the consensus like i've told you. >> >> Where is there an archive of the CVS log that is PUBLICALLY available? > >Hmm. Publically? Problem... maybe we should ask Jordan (or even the >whole hackers' list) to archive them at ftp.freebsd.org. My point is that the Bugs (and their fixes) are much more "public" than the CVS list. 99% (estimate) of the CVS log does not mean anything to someone reading the bug list. Therefore, I think it appropriate to put the info in the message changing/closing the bug. If someone really wants DETAILS, then the CVS area is the correct place. Access to that is a separate question. >> Agree. However, that points up a "problem" with the whole "SNAP-Release" >> system. Perhaps we need to have some way of tracking just what version of >> things is in that "release" eg: In the source files, we could/should >> include the .ctm_status files that reflect the updates that had been >> applied. > >It's not actually related to CTM, so this is not free of potential >raises. Perhaps it would be possible to collect all $Id$s into one >file. OTOH, the SNAPs are rather special in that they're not being >tagged on the CVS tree. For full releases, the CVS tags are a >sufficient method to retrieve the files later. Well, I think that they should be noted somewhere. Remember that many of us who are "testing" the -current stuff do not have access to the CVS tree. The public view of that tree is the -current tree. With the advent of CTM, I think it reasonable to use those numbers as the identification of interim builds of -current. For example, if I choose to build a kernel RIGHT NOW, you need some way to understand exactly which version of [pick something] I have included. ---- Richard Wackerbarth rkw@dataplex.net