Re: monolithic distro (was: Re: Fwd: Three weeks left - Mailing list pgsql-hackers

On Thu, 13 Jul 2006, Lukas Smith wrote:

> Joshua D. Drake wrote:
>> 
>>> Aside from obviously the big issue of who maintains all the pgfoundry
>>> stuff, I also think that the PostgreSQL family would benefit from a
>>> distribution that is more "and the kitchen sink" style. I do not know
>>> exactly if Bizgres could be considered just that? Or maybe it could get
>>> promoted to be that?
>> 
>> Lukas, that is what www.mammothpostgresql.org is :)
>
> Doh, yes .. totaly forgot about that one.
>
> Again I think it makes absolute sense to have a nicely sized core for all the 
> friendly forks to base their work on. However I think all newbie PR should be 
> directed at the monolithic distro and not to that nicely sized core.
>
> Cluefull people that want to create their own PostgreSQL distro will 
> naturally gravitate to PostgreSQL, while newbies come to PostgreSQL right 
> now. They dont find the feature they are looking for, and we miss out on 
> getting them into PostgreSQL.
>
> So what I am suggesting is that PostgreSQL.org should push people towards the 
> monolithic distro. The docs should contain everything that is in the 
> monolithic distro. At conference we should say the name of the monolithic 
> distro etc.
>
> Again, the truely cluefull people will naturally gravitate to the PostgreSQL 
> core project while the monolithic distro sucks in the newbies.

But, that isn't our role ... that should be the role of whomever takes on 
the role of 'maintainer' for such a monolithic distribution ... its no 
more our role to decide that pl/Java is better or worse then pl/J ... our 
role is to provide that core for everyone else to build around ...

People like CommandPrompt, Bizgres, EnterpriseDB, Pervasive ... they have 
the funding to *create* and maintain that, to make sure all the parts they 
distribute are working properly ...

The resources are there, if someone (you?) wants to do this as a FOSS 
project, but I fear that amount of work (both time and energy) required to 
make the 'include all, for all' distribution is much much greater then the 
returns will be ... the more you add in, the more you have to co-ordinate 
releases with the external projects, and pull/push old/new stuff in as it 
becomes 'stale', etc ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email . scrappy@hub.org                              MSN . scrappy@hub.org
Yahoo . yscrappy               Skype: hub.org        ICQ . 7615664