Description David Williams 2008-08-10 00:32:19 EDT

There's a number of issue to address so our builds can complete faster. 
(Overall, our builds used to take approx. 2 hours ... they now take at least 4 hours, sometimes 5 or 6). 

This umbrella bugzilla will be used to discuss or document this general family of issue. 

One item is to better document the times involved with the different build steps, so we can spot which parts take the longest and/or change over time. 

One suggestion that's been made is to not always sign every build. This is a very time consuming step. Some have argued each build should be signed, so each build is as much like the final build as can be ... but, it could be argued, that benefit is out weighed by the costs. One problem with _not_ doing it every build is deciding when to do it. If we do "after the fact" (only after we decide to "publish" a build) then there's a couple of issue in the way: a) we'd still have to normalize the jars during the build (also done during signing) which is a long process (but not as long as signing), and 2) we'd have some duplicate jars (such as those in zip files, and those in update site) that would then be separately signed ... probably ok, but we'd have to make sure (currently, once jars are signed, they are then used to create zips for downloads). 

Another possibility to investigate is to build "everything at once" and then break things into the separate packages/downloads as we need. The problem with our current method, which has some redundancy and a type of recursion in feature definitions, is that while PDE handles it fine, it handles part of it by "spinning it's wheels" for things it's already built ... and spinning them, for example, by trying to get something from cvs which it has already gotten, and just ignoring the "already exists" errors it gets. It works, but takes a while. so, if we had just one big "wtp" build, with everything listed once, then build that, and _then_ after the fact, break things up as needed. 

I'm sure there's other spots that might be inefficient ...