Skip site navigation (1)Skip section navigation (2)
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>