Vivek Khera <vivek at khera.org> writes:
> On Sep 19, 2006, at 2:25 PM, Andrew Hammond wrote:
>> it would be a good idea to at least get an idea of what is on that
>> list.
>
> A lot of nifty ideas can be had from how apache has set up their
> infrastructure: http://www.apache.org/dev/  of particular not is the
> services section, http://www.apache.org/dev/services.html
>
> I'll throw in the list of services I'd like to see:
>
> 1) CVS/SVN repo distributed to multiple public points
> 2) bug tracker
> 3) website content system (preferably one not built on PHP)  -- could be a wiki
> 4) mailing list manager

Seems to compare reasonably well to what I had in mind.  And it is
encouraging when others come up with similar answers; that means that
major things aren't outright missing.

What is really unfortunate is that there are too many legitimate
choices particularly for 2) and 3).  :-(

> The DNS needs to be fully redundant and manageable by multiple
> entities (preferably not just multiple folk at the same company).

I'll disagree slightly here, at least for the instance that we're
thinking about (e.g. - a single server hosted by CMD).  If there's
only one server, hosted in a single location, it probably *isn't* DNS
that will be the least reliable component.  (Unlike a certain recent
DNS outage situation!)

If the servers aren't distributed (e.g. - there aren't really multiple
of them), then there's not terribly much to be gained by adding this
complexity to DNS management.

> All project data needs to be remotely backed up on some regular
> schedule.
>
> The system as a whole needs to be backed up in such a manner that if
> the machine fails, a full restore of the system involves just the
> time to restore from backup once the replacement machine is powered
> up.  Configuring the system as a virtual machine using either vmware
> or some moral equivalent makes this part much easier, as the whole
> system image is just one file.

That's a pretty slick approach.  I was biasing to using some heavily
package managed Linux system, as that tends to keep customizations to
something of a minimum, but this approach allows ignoring that.
Things can get pretty messy inside the virtual environment; the mess
will happily migrate to a new VM.

> The "distributed" source repo would work like this: a central repo
> would be accessible to committers only.  The public repos would sync
> to this repo on some regular schedule, possibly triggered by a commit
> script.  The public would have read-only access to these mirrors.
> This is similar to how the FreeBSD project distributes software.

The only problem with that is that I only see one devoted server in
the near future.  That approach mandates having multiple servers.
It's nice, if you're being showered with hardware that way.  We're not
quite that showered...
-- 
"cbbrowne","@","ca.afilias.info"
<http://dba2.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)