Perhaps I haven't done a very good job outlining what the issues are
that I have.  Note that I'm wearing my project-sponsor hat right now,
speaking as the person whose management will demand what they're
getting for the money they're putting up for the staff time on the
project.

On Tue, Sep 19, 2006 at 12:08:04PM +0100, Dave Page wrote:
> > 
> > 1.	pgFoundry is not sustainable in the long run, because of the
> > problems Chris raised.
> 
> Why? Who says we've gotta keep upgrading? If we need any specific new
> features in the future then there's a good chance we'd have to scratch
> our own itch anyway, regardless of the status of the original project.

The problem with the software, as I understand it, is that it's a
tricky piece of infrastructure that is understood by a small number
of people.  That number of people may get smaller as people move on
to other topics or efforts, and no new familiarity is likely to
emerge from the wider community, because the version we're on is
abandonware.  But this is a secondary issue.  My main issue is the
following.

> Gborg is as secure as any of our other sites again. Believe it or not it
> really was a freak set of circumstances that led to the outage - and
> provisions have and are being put in place to prevent a recurrance.

The infrastructure for both pgFoundry and gborg -- not to mention the
entire postgresql infrastructure -- seems to be subject to certain
single points of failure.  The only proposal I have seen to do
anything about that is to add another person, who will be available
only for emergencies.

Now -- and again, please understand that I'm wearing a pointy-haired
wig right now -- we as a community are busily positioning
PostgreSQL-with-Slony as a fault-tolerant, high-ish availability
piece of software infrastructure.  We've been pretty clear in what
we've been saying that we're not really ready for five nines yet, but
that one can get pretty close by combining PostgreSQL with Slony-I
and some special OS services.  But as soon as we have the sorts of
outages we've had -- long outages, long times to backup restoration,
very bumpy restores that involve a lot of manual checking after the
fact, and fairly elementary-level DNS failures -- we completely
undermine the argument that we are offering "enterprise grade"
software.  If the basic services necessary to maintain, build, and
obtain the software fail, what conceivable reason does anyone have to
believe us that our software is ready for real, industrial use?

Now, I appreciate the difficulty (not to mention absurdity) of
setting up service level agreements with volunteers, and I understand
that nobody is being paid for these services.  The "unpaid" part,
however, is easy to solve, given that we now have a mechanism to
receive funds for these sorts of activities.  That leaves us with
only the problem of coming up with some sort of outline of what we
think we need, writing that down, and then building some support to
try to achieve that goal.  Nobody would accept big new features in
the back end without at least some sort of description of how it's
supposed to work, what the interfaces will be, &c.; why should we
accept any less for the necessary infrastructure to support the
project?

I believe that Chris's outline was an attempt to define the
infrastructure requirements.  Perhaps they're inadequate (re-reading
them, I suspect some refinement might be a good idea).  But it seems
to me that what we need to do is nail down -- whether for Slony or
for the PostgreSQL project more generally, if people like -- what
sort of service we would _like_, and how we are willing to compromise and
on which items.  Once we have that, we can proceed with the decision
around whether pgFoundry meets the needs of the project.  Does that
seem fair?

A

-- 
Andrew Sullivan  | ajs at crankycanuck.ca
When my information changes, I alter my conclusions.  What do you do sir?
		--attr. John Maynard Keynes