Date: Fri, 5 Mar 2010 09:17:01 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: paradox <ddkprog@yahoo.com> Cc: freebsd-current@freebsd.org Subject: Re: propose: all arch move into a separate dir Message-ID: <alpine.BSF.2.00.1003050912340.5181@fledge.watson.org> In-Reply-To: <619814.37821.qm@web59102.mail.re1.yahoo.com> References: <619814.37821.qm@web59102.mail.re1.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 4 Mar 2010, paradox wrote: > so, I really do not understand why it is so difficult to move a few folders > in the shared folder is a big problem as is done in openbsd and netbsd > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/?only_with_tag=MAIN > http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/ as you can see I would hesitate to say that there are "no" large forks of OpenBSD/NetBSD in products, but it may well be that the maintainers of those forks are less involved in their communities. We have downstream consumers like Isilon, NetApp, Juniper, and many others who have significant kernel features maintained against our tree. It's not just them either: we are our own downstream consumers. Every major branched project in Subversion, Perforce, or external git repositories, will have significant local changes. Every time we go wild rearranging the tree, they have to pick up the mess trying to figure out how to forward-merge changes -- and as someone who has been on the wrong end of that (the TrustedBSD work took 5+ years to go from inception to merge), I can say it's a really painful experience. It's not impossible, it's just a huge amount of work. This isn't to say we shouldn't do occasional rearrangements, but the argument has to be made pretty carefully that the gratuitous rename of the day offers a significant benefit, worth potentially dislodging all the downstream trees and requiring them to remerge all their work. It can't just be "oh, if only we had five fewer directories at the top of the sys tree", because that's *not* worth it. Doing that kind of rearrangement on the network stack would be a nightmare for anyone with large network stack patches, so I'd say we could pretty much rule that out outright. I'm not sure how things compare in the machine-dependent code trees, but I'd guess there are people with non-trivial changes there as well. Robert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1003050912340.5181>