Date: Sun, 17 Mar 2002 01:08:43 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Murray Stokely <murray@FreeBSD.org> Cc: obrien@FreeBSD.org, sobomax@FreeBSD.org, re@FreeBSD.org, current@FreeBSD.org Subject: Re: HEADS UP: -CURRENT Feature Slush is OVER Message-ID: <3C945D1B.61ECDDD3@mindspring.com> References: <20020316111818.GO17499@freebsdmall.com> <1016289691.91096.2.camel@notebook> <20020316115309.E95652@dragon.nuxi.com> <3C93C273.8356D01@mindspring.com> <20020317083315.GO19657@freebsdmall.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Murray Stokely wrote: > On Sat, Mar 16, 2002 at 02:08:51PM -0800, Terry Lambert wrote: > > I think it's an incredibly bad idea that we are not going > > to be able to reproduce what went onto any given CDROM in > > ten years. > > I agree that it is very important to be able to reproduce official > releases of FreeBSD N years down the road. However, that has never > been a requirement of snapshot CDs. We have never even tagged the > tree for previous snapshots. We are actually moving more in the > direction you advocate by at least moving the snapshot production into > Perforce so that more developers can participate. The release > engineers would prefer to do this in CVS, but that is not advisable > for the reasons Peter outlined in his mail. The source distribution > is included in the output of "make release" for a reason. If you have > a technical solution to the problems that Peter raised, then I'm sure > cvs@FreeBSD.org would like to hear about them. Minimally, pick a date, and then do a CVS diff against that date, and include it on the CDROM. Max wants the commit messages to the developers pre-release to go to an archived mailing list for similar reasons, it seems to me. Without the deltas against something that is fixed in the repository going forward, it's simply not going to be a useful exercise, since it's not going to be possible to make changes without a crib-sheet of how to wave the dead chicken over the source code. Erasing the crib-sheet is a really bad idea. Imagine that you have the developer's prerelease, and you have a bug (because you're a developer who's using the pre-release). Now say you have become involved in the process, because the pre-release has done it's job. You want to fix the bug. In order to do this, you are going to need the delta against the developer's prerelease source tree. To get this, the process is: 1) Before you make any changes, copy /usr/src to /usr/src.org OR mv /usr/src/usr/src.new reinstall /usr/src using /stand/sysinstall mv /usr/src /usr/src.org mv /usr/src.new /usr/src 2) Make your changes 3) Run diff -cr /usr/src/org /usr/src 4) Now, figure out how to apply these diffs to the CVSup image of the -current CVS tree for some checked-out version of -current AND Pray to God that the code your changes are in are not in code where changes were backed out or made by the release engineers for the developer's pre-release OR Install -current somewhere, with -current sources, hoping that it runs at all, and the release engineering work for the developer's prerelease was useless in your case, so that -current runs for you without trouble so that you can make your changes against -current, instead, so that it's possible to submit them back to the project and have them have meaning, in the larger scheme of things. It's really, really not happy for the CDROM to have no relevence to the developement process, if the entire purpose of the CDROM is to get more people involved in the developement process. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C945D1B.61ECDDD3>