Marc G. Fournier wrote:
> Except that what you are missing is that each if the individual
> package is 'supported' to a certain extent, it doesn't negate the
> amount of work that the developers (more often then not, the core
> developers for stuff like this) having to maintain and test the build
> system ... and the more we 'include', the more onerous that task will
> be until such a point that the 'core server' won't get any work done
> on it, since all the time will be spent on "packaging the latest and
> greatest solution for foo" ...
Moving things in under the PostgreSQL does not have to be equal to
moving all the work over to the core developers.
The contributors must of course still do what they do today. That
includes testing (and documenting, answer questions on mailing lists,
etc.). A great advantage would be that this time the testing would be
made using a common test infrastructure enforced by the (extended)
comittee and the documentation would become part of the PostgreSQL docs.
In essence, you would actually get more people involved in the common
infrastructure, thus lessen the strain on the core developers. I said
before that I don't doubt for a second that you are totally busy with
the core backend. My suggestion is not that you take on more work but
rather that the comittee is allowed to grow and take on responsabilities
and people beyond the developers of the core database.
>> In times when people download gigabytes of film and music using
>> BitTorrent, I think that's the least of our problems. But of course,
>> the distribution should be kept at a reasonable size. That's why I'd
>> like a better solution to replace the inferior one and to limit the
>> number of overlaps.
>
>
> At which time we are once more 'playing favorites' ...
Sorry, but that one got right pass me. 'playing favorites'?
Regards,
Thomas Hallgren
