Date: Wed, 3 Jul 1996 23:40:09 -0600 (MDT) From: Nate Williams <nate@mt.sri.com> To: Peter Wemm <peter@spinner.dialix.com> Cc: James Raynard <jraynard@jraynard.demon.co.uk>, gpalmer@freebsd.org, alex@fa.tdktca.com, mpp@freefall.freebsd.org, CVS-committers@freefall.freebsd.org, cvs-all@freefall.freebsd.org, cvs-usrbin@freefall.freebsd.org Subject: Re: cvs commit: src/usr.bin/quota quota.c Message-ID: <199607040540.XAA07322@rocky.mt.sri.com> In-Reply-To: <199607040137.JAA14584@spinner.DIALix.COM> References: <199607032044.UAA01957@jraynard.demon.co.uk> <199607040137.JAA14584@spinner.DIALix.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
> > What's the "approved" way to import Lite-2 code? (Sorry, I don't have
> > a CVS tree to look at at the moment).
>
> There is actually a pretty good reason why we have not done a bulk import
> of the Lite-2 code to the userland areas.
[ Excellent explanation deleted ]
> There are four options here..
>
> 1: commit to all files in userland to get them onto a stable code line, so
> we can import Lite2 and nothing will happen until somebody manually merges
> it in at their leisure. Simply adding a $Id$ to *every single file* would
> do this. Once it's done, import the whole lot, and gradually pull in the
> new stuff as needed.
>
> 2: Set something up so that anybody can import Lite-2 from the cdrom and
> have a reasonable chance of succeeding... easy-import was meant to help
> this, but we still seem to have a lot of hassles with it, so I dont know
> what the answer is. Perhaps just a good set of instructions and a "how to
> import stuff" is what is needed. But then, as we've found with the ports
> tree guidelines, many people still dont read the docs.
>
> 3: Import the tree bulk, allowing userland to be broken, then set
> everybody loose merging it in to fix it. This would have the advantage of
> getting it over and done with, but it would cause chaos along the way for
> a week or two.
>
> 4: Do nothing - it's too hard, and do the imports piecemeal, like sys,
> lpr, sh etc so far...
>
> By default, we seem to have ended up with #4, at least until the kernel is
> updated to use the Lite-2 interfaces. If a couple of people with a lot of
> spare time also understand the Lite vs. Lite-2 changes in the kernel
> interface that have not been completed yet would be interested in doing a
> gradual update, module by module, resolving the conflicts as they go, then
> I guess I could instruct them in how to deal with importing the lite-2
> code and we could let them loose.
>
> Do we want to do this? Going for a flag-fall day for importing the lot
> would certainly get it done quicker...... or should we wait for the
> Lite-2 parts of the kernel to arrive so that we dont have to keep parts of
> Lite-1 around?
I'd like to see the current -current tree branched right before this
happens, and then let people have at it. Make sure you give some folks
plenty of time to understand what's going on, and then let the
developers hack on the 'broken' tree until it works, at which point we
can merge any changes people have made on the 'stable' branch back onto
the now working development branch and life goes on. And, if things are
going really slowly/badly or if you're nostalgic you can call the
'pre-Lite2' branch 'stable' and the 'post-Lite2' branch 'current' and
cut the next release from the 'stable' branch.
{ Quickly donning his asbestos underwear }
I know people hate CVS branching, but short-lived branches work
exceedingly well *AS LONG AS* you understand the limitations of
branching (which are a problem in all SCM tools).
Nate
[
Wishing he wasn't here to answer email, but my 95 Neon blew a head
gasket 60 miles out of town, so now I'm back at home trying to figure
out how to get outta town tomorrow.
]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607040540.XAA07322>