Warner Losh writes:
> In message <[EMAIL PROTECTED]> Jason Evans writes:
> : Summary: -current will be destabilized for an extended period (on the order
> : of months). A tag (not a branch) will be laid down before the initial
> : checkin, and non-developers should either stick closely to that tag until
> : the kernel stabilizes, or expect large doses of pain. This tag will be
> : laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning
> : beforehand.
> Thanks for the fair warning. Now don't do it. Has core approved
> this? I don't think so, I've seen nothign from them about it.
> The instability ni -current for MONTHS is pain not acceptible. We've
> never really allowed that in the past. A CVS branch would be mcuh
> better for this sort of thing. I know that's a pain as well, but this
> is just for SMP people and the rest of us shouldn't have to deal with
> the pain.
As someone who does consulting on for release engineering and such
things, I'll comment that that's one of the key uses of branches;
buliding a development branch so that adding major new features
doesn't disrupt other development until they are as stable as the rest
of the project.
If CVS makes merging a branch back in a pain, and there isn't an open
source tool (bitkeeper, maybe?) that solves this problem, then
possibly a compromise can be reached with the folks at
Perforce(*). They're reasonable people, and think highly of the
FreeBSD project. "The Cathederal and the Bazaar" talks about
transitioning from closed to open source, so I'd be very surprised if
they haven't thought about these issues.
As a for instance, possibly they could be talked out of sources for
the client (client libraries, that is - the rest is trivial) and a
spec for talking to the server, on the assumption that the truly
valuable information is in the server. That way, the tools installed
by developers would all be open source. Of course, Perforce may have
no interest in this, but I can't think of anything more likely to
convince them to make such a move than the possibility of the FreeBSD
project moving to Perforce.
> I understand your desire to have it all in a working tree, but causing
> pain for ALL developers for potentially MONTHS isn't a reasonable
How far can the tag be stretched to make things work? Can CVS tags be
changed to include updates versions of a file, so that there is some
possibility that other developers could work with that tag, instead of
creating another branch?
*) While I am a Perforce Consulting Partner, I have no official
position with Perforce, I am *not* speaking for them, and I'm not
privy to any of their strategic planning. If you want to know what the
folks at Perforce think about any of this, ask them.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message