Date: Fri, 7 Jun 1996 21:58:35 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: davidg@Root.COM Cc: nate@sri.MT.net, jkh@time.cdrom.com, hackers@freebsd.org, freebsd-stable@freebsd.org, FreeBSD-current@freebsd.org Subject: Re: The -stable problem: my view Message-ID: <199606080458.VAA05346@phaeton.artisoft.com> In-Reply-To: <199606080406.VAA12386@Root.COM> from "David Greenman" at Jun 7, 96 09:06:31 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >This kind of work is necessary for -stable to exist, and apparently at > >least Jordan and David are completely unwillingly to do this. Do any of > >the developers (and Peter the CVS-meister) have anything to say? > > I've obviously been willing since I've been doing this for over a year now. > The problem is that I have no time to work on new development myself. New > development is the "fun" part of FreeBSD. I haven't had any FreeBSD "fun" for > more than a year now, and I'm quickly approaching the burnout point (actually, > I've already burnt out; I'm currently forcing myself to continue in this role > only because I feel obligated to get the release out). > This is a difficult problem for me. I've intentionally placed myself in- > between the release tree (which is currently -stable) and -current in an > attempt to improve the quality of FreeBSD releases. If I decide not to do this > any longer, then I'm affraid that the quality of the released code will go > into the toilet. We need a new model. One that keeps the quality high and one > that doesn't prevent me from doing new development. The "grunt work" of synchronization needs to be automated, as much as possible, to move the load off of David. I've been where he is now (I still am, in some respects, with some of my unintegrated code), and it is not a happy place to be. I'm certainly not saying that moving -current to being closer to the goals of -stable by enforcing buildability is the *only* way, but it is most certainly *a* way. The build/token process is *another* way. I think the token process is only necessary if you can't guarantee a buildable tree at checkout (which is where I'd like to see the problem attacked). The token process also only guarantess some *eventual* success, and can't be seperately tagged, apart from checkout time, which makes it painful to build world. I think this is too intermittent to leave the -stable repository mirror of a snapshot of the -current repositopry working. An alternative (which isn't reasonable at this time) would be to provide a mechanism for CVS tree migration based on delta-tags, so that deltas up to the tag date that don't exist in the -stable tree are imported to the -stable tree based on a successful build. This grants some control over "when to move up stable" seperate from "every time a build succeeds", in a nicely automated way. I like this last (though unreasonable) way because if I allow conflict resoloution at each stage of the integration process for the delta segments, I've just bought myself the ability to maintain multiple source bases and integrate them, if only by date-cutting myself copies of the CVS tree for each one of the sub-projects I want to work on, and I can merge them into a combined project (to work on my overpass, I was talking about before). I'd still be missing the pice that lets me adjust the "merge-from" tree to resolve the conflict instead of the "merge-to", but it's a hell of a lot closer to ideal to be able to insert one delta at a time from one CVS tree (-current) into another (-stable) to incrementally update it. The missing piece is a global change log (from the writer unlock logs, presumably) to insert deltas as change span sets, so that I get all of the deltas for one self-consistent set of changes in one update/merge. I haven't spent any real time looking at CVS to see what it would take to stuff non-merge deltas in, one at a time, from another (later) tree to get a -stable tree, let alone looked at the issues of conflict resoloution for multiple tree merges. Clearly, a first step would be to tag the tree at the replication point so that local changes could be distinguished from conccurent changes in the "real" tree... from there, it would take a bit of CVS hacking to work out. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606080458.VAA05346>