Upayavira wrote:
[EMAIL PROTECTED] wrote:
True! However, if there is a form to be filled in, some questions will be answered beforehand, thus eliminating several mails back and forth.
Some of the questions: - how can I see that Cocoon was used? - why did you use Cocoon? - how much time did the project take? - how many members did the project team have?
Hi Helma,
You asked previously about what it would take for us to be able to run Cocoon on Apache hardware. At the moment, Apache has something like six machines, and these are guarded (quite rightly) fiercely by the intrastructure team, in order to keep them suitably secure.
There are a lot of projects that would like to have access to Apache hardware, whether for hosting, or for build/test cycles. In part, as a way to cater for this, the infrastructure team is building a couple of those machines to run VMWare ESX - thus they can host multiple operating systems on each machine. ESX is working, but they need to get more HDD/memory for it to handle more VMs. If we have needs for running our own stuff, e.g. having the latest Cocoon samples usable from the Cocoon website, we should make a request to the infrastructure team for a VM for ourselves, as soon as they have done the necessary hardware upgrades.
This would of course require us to choose an OS/distribution (never easy in a diverse community!) and then to maintain it.
Are people interested in pursuing this?
In the meantime, using our existing mechanisms, we should do as Antonio suggested - improve the notes on the livesites page, stating: Put an entry entitled [LINK] Blah into bugzilla, and answer these questions. If you don't answer them, your request will not be considered.
Or something like that. What do you think?
FYI, I have root access on brutus.apache.org (the machine that runs gump) and we could start to proxy_pass from cocoon.apache.org on to brutus.
The machine is a dual xeon, 4Gb of ram, SCSI disks, runs JDK 1.4.2 and has a MySQL database installed.
The machine is considered "not highly secure" by infra@ since it executes code that we don't control. If we can live with that low security, we can route around infra@ concerns and move on.
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
