From owner-freebsd-current Sun Mar 17 0:57:33 2002 Delivered-To: freebsd-current@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id A3F4637B402; Sun, 17 Mar 2002 00:57:22 -0800 (PST) Received: from pool0050.cvx40-bradley.dialup.earthlink.net ([216.244.42.50] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16mWTb-0000jE-00; Sun, 17 Mar 2002 00:57:16 -0800 Message-ID: <3C945A4A.3FC77CB1@mindspring.com> Date: Sun, 17 Mar 2002 00:56:42 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: obrien@FreeBSD.org Cc: sobomax@FreeBSD.org, re@FreeBSD.org, current@FreeBSD.org Subject: Re: HEADS UP: -CURRENT Feature Slush is OVER References: <20020316111818.GO17499@freebsdmall.com> <1016289691.91096.2.camel@notebook> <20020316115309.E95652@dragon.nuxi.com> <3C93C273.8356D01@mindspring.com> <20020317002235.B3875@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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