On Tue, Apr 16, 2013 at 02:07:45PM +0100, Noah Slater wrote: > Okay, some success. > > Here is a mail sent to infrastruct...@apache.org: > > On 16 April 2013 13:44, Tony Stevenson <pct...@apache.org> wrote: > > > Noah Slater wrote on Tue, Apr 16, 2013 at 01:33:39PM +0100: > > > Hi, > > > > > > It recently came up on the CloudStack list that if cloudstack.org moves > > > over to ASF control, we would not be able to point foo.cloudstack.org at > > an > > > external VM. (Say, a committer is running a CI/build/whatever service.) > > Is > > > this the case? Are there any exceptions to this? > > > > > > I ask not because I want to drag up old discussions for the sake of it, > > but > > > because we have some ongoing trademark stuff with CouchDB, and one of the > > > things I am planning to propose is that we move couchdb.org to ASF > > control. > > > > > > But if the above is policy, that wouldn't work. > > > http://docs.couchdb.org/points at a third-party hosted service, for > > > instance. And we are working on > > > a Jenkins setup that is not on ASF hardware (because the ASF is unable to > > > provide us with the hardware we require at this time). > > > > > > Could someone clarify this for me? > > > > Noah we have several instances of DNS records pointing to non-ASF hosted > > services. We would clearly very much prefer that we didnt have to do > > this, but I do not believe it is against policy. > > > > Our issue comes from the fact the machine is not under our control, and > > as such anyone could just add $bad-content within the apache.org > > namespace. At the moment, from memory, all records that point to > > non-ASF hardware, are still machines we control. Your asking for > > something above and beyond this, and I suspect if this is what the PMC > > wants then that would be done. But it would need to be requested, > > following a vote thread and that link given to us so we can see the > > process :) > > > > This is from a private list, but I have been granted permission to share it > with this one. > > For those with the appropriate karma, the thread starts here: > > http://s.apache.org/ZLE > > So, if we put together a definitive plan of action for the domain, and the > services we want to host / point to, along with who is operating them, and > what the plan for that is, and vote on it, it looks like we can proceed. > (But we should be mindful of Infra's concerns, and take them into account > while drafting the proposal.) >
Thanks Noah. That helps clear some confusions. But I've moved jenkins.cs.o to a different namespace as was done before with docs.cs.o. jenkins.cs.o now resides at jenkins.buildacloud.org. One of the difficulties for moving our jobs to builds@ was the performance and hardware considerations. I think some infra@ folks are aware of the problems we have with having to stack up enough hardware to run tests for our system. Having a separate managed jenkins is useful for us to quickly fix problems as is often the case with automated testing. Some of the other cs.o services are managed by David and myself. David has the necessary karma within infra to look into these when things go bad. Unless others feel that the services should remain on cloudstack.org I think we have a reasonable backup plan for now. Anyone think otherwise? -- Prasanna.,
