Re: propose: all arch move into a separate dir

From: Robert Watson <rwatson_at_FreeBSD.org>
Date: Fri, 5 Mar 2010 09:17:01 +0000 (GMT)
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
Received on Fri Mar 05 2010 - 08:17:01 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:01 UTC