On 5/16/2011 12:27 PM, Johnny Hughes wrote: > > The point is that we do not have a system built that can track that sort > of stuff ... and we can either build packages or design systems to track > stuff. You don't really have to design a system for build automation/tracking since there are several free ones available. Of course there is a tradeoff in terms of how quickly the automation would win back the time it takes to configure it. > We are working on a new website design. > > We opened up a new QAWeb. > > We have an announce list. All great, and much appreciated, particularly compared to previous postings that implied that nothing needed to change or was ever going to. Still, I don't see how these help with the underlying issue of resources unless the bottleneck is in post-build QA. > As far as build logs are concerned, they reside on the build server ... > where we had people try to "break into". That machine is now hidden and > references to its name are also hidden. We can't have people pounding > away against important servers ... there is no such thing as a > completely secure setup. We therefore will not make our build machines > open to the public. Agreed on the security comment, hence the concern about timely updates. It is pretty much a given that any public site will be hit with all known exploit attempts, but it is somewhat unsettling to think that the project itself considers that to be a problem. But, most of both the 'pounding' and security issues can be handled with a simple caching reverse-proxy server easily configured in squid/apache/nginx, etc.. And with build automation frameworks like jenkins/hudson, the results and logs are collated on a central server that mostly does scheduling, not the actual work: http://ci.jenkins-ci.org/builds. -- Les Mikesell lesmikesell at gmail.com