[EMAIL PROTECTED] (Chris Seawood) writes:
> 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.
Sounds like a fine plan.
> 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 is a difficult question, for sure. The current strategy of
pulling everything is convenient for folks who make API changes that
require spanking the entire tree. But I tend to agree with you that
the default checkout should be small, and people that want the extra
stuff should be required to ask for it explicitly.
> 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.
Extensions was specifically intended for optional stuff.
> 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.
Perhaps all subdirs of extensions should be treated as individual modules by
client.mk. This would eliminate the need to have a hardcoded list at
all.
Dan
--
