Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 8 Apr 1995 17:12:24 -0500
From:      rkw@dataplex.net (Richard Wackerbarth)
To:        joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
Cc:        current@FreeBSD.org
Subject:   Re: closing bin/295
Message-ID:  <v02120b07abacb819a8f1@[199.183.109.242]>

next in thread | raw e-mail | index | archive | help
>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





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v02120b07abacb819a8f1>