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.