[SAC] Project Hosting

[christopher.schmidt at nokia.com]

On Jun 14, 2010, at 3:28 PM, ext Howard Butler wrote:

> 
> On Jun 14, 2010, at 12:54 PM, <christopher.schmidt at nokia.com> wrote:
>> pgRouting is a mature project, 
>> well-documented, with a significant history in the OSGeo community
>> (participation at conferences, etc.) There is no reason they
>> should not be pursuing incubation that I can see.
>> 
> 
> As far as precedent goes, we didn't put this condition on PostGIS when they came to us for hosting help. Or GEOS. 

I agree, and I think that is unfortunate. I'm not arguing changing
the past, but as we grow, our hosting actually does cost real money.
We recently had to make the transition from osgeo1 to the OSUOSL
hosting precisely because of the growing usage of trac/SVN -- 
load on that machine has gone down by 75% since the transition.

Free-for-all hosting is not practical, and I'd like to encourage
us to keep that in mind.

>> If a project is mature enough to be considered for incubation,
>> but is not interested in pursuing incubation, I feel like SAC
>> should take care in taking that project on as a hosting 
>> candidate.
> 
> I understand this sentiment, but a project without a "champion"
> within SAC to be responsible for their project is going to be at
> the mercy of volunteerism's ebbs and flows regardless.

To be honest, I don't see evidence of that. My observation is that
projects which are not undergoing incubation are expecting the 
same performance as every other project. In addition, the resources
for these projects are shared for all projects -- we didn't have
the option to tell PostGIS "Okay, we're not hosting you anymore
because if we continue hosting you, we'll have to migrate to a 
new hosting solution."

> An
> incubation-worthy project that would rather just freeload system
> resources from SAC either needs to bring with or create its
> champion within SAC.

For the the initial setup cost of a transition, sure; though I've
now simplified that so much that it could practically be automated.
For ongoing promises on performance and the like, SAC is equally
responsible to all projects, and there's nothing we have done about
that so far. (The idea of a seperate SVN for projects that aren't 
actually incubated with fewer resources dedicated to it would
theoretically solve this problem; in reality, it would probably
just make the initial headache more complicated to the point
that it's not worth it.)

Having done a significant chunk of the work on the transition
from one server to another for SVN/Trac, I can state categorically
that there is a fair amount of effort expended there for projects
that I would not have volunteered to do it for. I can't say for
sure that projects wouldn't have seen the same need to transition
without all the extra projects, but I certainly think it's a
possibility.

In any case, I think we need something more informative to projects
looking for hosting than ignoring SAC tickets, if no one is willing
to champion them. The PostGIS ticket has been sitting for a couple
months; if no one is willing to step up, then I can respond and let
them know that right now, there are no SAC volunteers to do a 
transition.

Best Regards,
-- 
Christopher Schmidt
Nokia