Re: inclusions WAS: Increased company involvement

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: inclusions WAS: Increased company involvement
Дата
Msg-id 4569.24.211.165.134.1115170336.squirrel@www.dunslane.net
обсуждение исходный текст
Ответ на Re: inclusions WAS: Increased company involvement  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: inclusions WAS: Increased company involvement  (Josh Berkus <josh@agliodbs.com>)
Re: inclusions WAS: Increased company involvement  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Josh Berkus said:
> Dave, all:
>
>> This issue has come up before, and I opposed it then when the
>> interfaces were removed from the main tarball.
>> I really don't see the upside to reducing the size of the tarball at
>> the expense of ease of use. Â Seems to me we are
>> bending over backwards to make it easy for people with dial up
>> connections to download our "enterprise class"
>> database.
>
> Small tarball size isn't the *primary* reason for having our
> "push-it-out-to-pgFoundry" attitude, it's the *tertiary* reason.  The
> main  two reasons are:
>
> 1) If we start including everything that's "useful", where do we stop?
> There  are enough pg add-ins to fill a CD -- 200 projects on GBorg and
> pgFoundry and  others elsewhere.  And some of them probably conflict
> with each other.  Any  decision to include some projects and not others
> will alienate people and  possibly be a mis-evaluation; the
> libpq++/libpqxx mistake comes to mind.
>
> 2) As long as we're using CVS, the only way to organize autonomous
> project  teams that have authority over their special areas but no
> ability to change  central code is to "push out" projects to separate
> CVS trees.
>
>>From my perspective, putting together a coherent "distribution" of
>>PostgreSQL
> with all the add-ins you want is the job of commercial distributors and
>  possibly OSS projects like Bizgres.


This water-torture campaign is disappointing.

How many projects on gborg have any active maintenance? Our community is
still small - we can ill afford fragmentation.

Tom and others have already pointed out the good technical reasons for not
divorcing PLs at least from the core code.

I was not around at the time of the libpq++/libpqxx issue. But, honestly,
fear of making a wrong decision should not be a reason not to make one.

As for CVS - if we can't do development the way we want using it then it's
time to replace it. I have been convinced for quite a while that it is
living on borrowed time, but I am far less certain about what should be used
to replace it. But making macro content decisions on the basis of what we
can do with CVS is just crazy.

cheers

andrew




В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: pg_locks needs a facelift
Следующее
От: Tom Lane
Дата:
Сообщение: Re: A proper fix for the conversion-function problem