I'm not quite sure who's in charge of what gets checked into the tree
anymore but the tree needs to be cleansed...badly. We constantly
checkout things that are *never* used by anyone anymore (psm-glue, pics)
as well as some things that are only used by a select few (embedding/qa,
manticore). I'm not as concerned about the size of these things as much
as the time it takes to check the cvs server against these unused files
that have absolutely no impact on the build regardless of which obscure
configure option you use. Yes, I know a super-duper fast-update.pl
script is in the works but that's only masking the problem. At some
point, we have to say, "That's enough" and start ripping out this
useless stuff. I've reached that point. I've already filed some bugs to
remove obsolete configure options and defines.
Obsolete/bitrotted/non-seamonkey directories are next on the list.
The problem is...where do you draw the line? psm-glue & pic are obvious
candidates of things that shouldn't be pulled any longer. Manticore,
however, is less so. For those who aren't aware, manticore is an
embedding project that uses C# & the .NET framework. I'll never use it
but it has obvious value to someone, I assume, otherwise it wouldn't
have been checked in to the tree. Does it need to be pulled by everyone
though? I'd argue not really. Having manticore in the tree doesn't
hurt anything but at the same time, it's not helping the majority of us
either and is questionably not part of the SeaMonkey project. Again,
where do you draw the line? What if someone wanted to check in a
GNUstep-based embedding project or a galeon-equivalent (provided the
licenses were compatible)?
This problem is, in part, caused by our penchant to use extensions/ as a
dumping ground for new modules that don't quite fall into the existing
toplevel directory structure. I don't know if the dumping occurs
because extensions was meant for optional stuff or if it's just a
convenient place to put stuff that will get pulled by default. I
suspect a bit of both. Rather than doing a 'cvs rm' on these
questionable parts of the tree or constantly having to modify the cvs
modules list to handle these individual additions, I suggest moving
master list of what gets pulled into client.m[a]k. Or maybe some perl
script that can be shared with the Mac as well. Whatever. It would be
something that allows mozilla.org to create the definitive list of
modules that compose the bare-minimum Mozilla (or not-so-bare Mozilla)
and allow the developers to add on whatever side-projects inside the
tree that they also care about (to pull as well as build). It won't be
perfect as it may increase the chances of someone not building a certain
configuration that affects others (namely, tinderboxes) but that happens
today as well.
- cls, tree janitor
