Date: Sun, 17 Mar 2002 00:56:42 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: obrien@FreeBSD.org Cc: sobomax@FreeBSD.org, re@FreeBSD.org, current@FreeBSD.org Subject: Re: HEADS UP: -CURRENT Feature Slush is OVER Message-ID: <3C945A4A.3FC77CB1@mindspring.com> References: <20020316111818.GO17499@freebsdmall.com> <1016289691.91096.2.camel@notebook> <20020316115309.E95652@dragon.nuxi.com> <3C93C273.8356D01@mindspring.com> <20020317002235.B3875@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David O'Brien wrote:
> On Sat, Mar 16, 2002 at 02:08:51PM -0800, Terry Lambert wrote:
> > I hate this whole direction.
> >
> > 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.
>
> The source will be on the CDROM. Nor is there any major importance to
> DP1. Are you also upset that you cannot reproduce the July 17th, 1998
> -CURRENT snapshot CD from WC?
I have to say that I feel incredibly strongly about this
issue, and so I'm going to argue passionately. Please bear
with me...
Taking your example, yes. ISO images by date should be reproducible
using the date stamp.
If "the July 17th, 1998 -CURRENT snapshot CD from WC" has
things on it that didn't come as a result of merely a straight
build as of a datestamp, then we've lost some of our history.
In that case of that version, it's likely that if anything
was done in a Mickey Mouse way, it was that the X11 distribution
or some of the DOS programs or whatever were copied from another
CDROM. That is, at least in theory, reproducible, though a heck
of a lot more inconvenient than a list of what was done in the
"README.CDROM" file in "/" on the thing would have made it.
In the "transient Perforce branch" case, when the branch
goes away, it's unreproducible completely. Any of the
changes that were necessary to make the thing compile, or
to back out broken code are lost. It's now inpossible to
identify, from records, what the release engineers found to
be broken enough that it had to be backed out or patched
around, and it loses the back out and the patches.
I'm not entirely sure that the resulting image will in fact
be on the cdrome; even if it were, the results are not
diff'able against the repository without a huge amount of
manual effort.
Basically, we're losing history, and, unlike the "July 17th,
1998 -CURRENT snapshot CD from WC" case, which is barely
acceptable to lose, since it is "repo + reproducible deltas",
it becomes "repo + unreproducible deltas".
I would have liked it if a tag had been laid down immediately
after the BSDCon Developer's Summit, and then moved forward
or backware on a filed basis, with a branch tag at freeze
equal to the moving tag, checked out, with any additional
changes after the freeze done in the context of the branch
tag, so that they're recoverable.
It seems to me that, at worst, this is being done to "prove
to the heathens" that use of Perforce is a bad idea. It
certainly is, if history is going to be lost, but that's not
a result of the tool, here, it's a result of intention.
At best, Perforce is being used because the release engineers
have less power over branching in the CVS repository than the
core team *should* be loaning them.
Either way, it's bad news when it won't be possible to
reproduce an official code cut -- even if it's not a
release -- from the repository.
What is a repository good for, if you can't recover your
history from it? The way Linux is developed, they release
code that's not recoverable from a repository, ony from
the release materials themselves. They have no repository
because they *intentionally* have no perception of history.
Actually, it's possible to lay down a tag in the past: do
a checkout of the sources as of the day after the BSDCon
Developer's Summit (or whatever feature freeze date is right
for the preview), and then lay down a tag on the code checked
out as of that timestamp.
I don't understand the use of Perforce, in this case, unless
it's as a strawman to try and prove all fish are trout because
one fish is a trout ("Perforce is a bad idea in all cases
because it's a bad idea in this case").
If my position is unsupportable in everyone's opinion, so
be it: I would like an official policy statement on what
will, guaranteed, be reproducible from the repository, when
it comes to officially sanctioned distributions, like a
-RELEASE CDROM, or like a "Developer's Preview".
In that case, I'll basically ignore anything that isn't in
that list.
This developer's preview, if it's not reproducible, isn't
going to be delta-able, and so won't be improvable: if I
have a problem with it, and fix the problem, there's not
going to be a delta against the repository from which I
can derive a patch for inclusion in FreeBSD going forward.
If the purpose of this release is to get developers hacking
on the code and fixing problems prior to 5.0-RELEASE, it
*really* needs to be hackable for it to be hacked on.
Otherwise, all it's going to do is be confusing when things
work in the developer's pre-release because they were fixed
in a now non-existant branch, and don't work in -current...
NOT because the were broken in -current between the
pre-release and the time they were attempted in -current,
but because they NEVER worked in -current in the first place.
If that's going to be the case, then I have to say that
everyone will be better off if they ignore the CDROM of
the "Developer's pre-release", and stick with -current,
since at least your patches will be applicable to future
work, instead of lost in some non-existant dead-end.
-- 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?3C945A4A.3FC77CB1>