Re: Unsupported 3rd-party solutions (Was: Few questions - Mailing list pgsql-general

Is this one more incarnation of the packaging, release-announce and what
has to be CORE or not discussions?

Well, the fact that the discussion is going on and on does indicate that
the project "management" doesn't do a good job here. We have repeatedly
stated that the core project doesn't have the time, resources or
whatever to evaluate all those auxilliary projects and therefore we
can't put together a list of recommendations. I think this true ... in part.

The true part is that the core project (not the CORE team alone) does
not have the resources to review or evaluate all this. We probably don't
even have the skillset to make any educated guesses about it. But I
would say this is true about every project I ever have been a member of
or every job I have been in.

Probably one of the outstanding abilities of the best managers I have
ever worked for is "management by deligation". This does not mean to
deligate work, but to deligate decisions. And then to go with that
decision, accept it and to defend it.

Just because we don't have the skillset ourselves cannot mean that we
leave the PostgreSQL user community in a decision vacuum. I don't think
anyone really likes to be responsible for decisions he didn't make. But
I guess that is what we have to do because our continuous "we don't
know, it's your choice, pick your own poison" is just not what anyone
wants to hear. And interestingly it is what most of us do anyway. How
many of us really have the skillset to make an educated decision about
the exact implementation of PITR features, the best strategy for buffer
replacement, how to start/stop/throttle background writing of dirty
buffers or why and when xid's should get frozen or not? Honestly, I do
not know the answers to most of the questions that have to be decided
inside of the core server these days either because I don't have the
skillset or because I didn't have the time to figure it all out myself.
Does that mean that I will not have to defend the way we do savepoints
tomorrow? Nope, I will have to live with it and carry that decision to
shows and events and everywhere as if it was my own one.

Now what is exactly the difference between those "core" feature
decisions and the "auxiliary" or "3rd party" things? The fact that their
code isn't part of our tarball is only an excuse for not making any
recommendations. I don't care what type of admin tool the PostgreSQL
community suggests for package maintainers to include in every standard
installation of our database. I don't use any of them myself. But every
single of them is certainly a lot better that our repeated *shrug*.

If we need user- or community votings on this, then lets do them. Let us
stop telling people that nothing is good enough to be recommended by the
PostgreSQL team. It is not true. There are a lot of things and add on
products out there that are. And if 70% of our users vote for "C", then
putting that onto a recommenation list is certainly not the worst.


Jan


On 8/23/2004 5:25 PM, Bruce Momjian wrote:

> As an example, who has the largest 8.0beta1 downloads?  pginstaller.
> And who controls that?  The pginstaller project team.  It has no
> official relationship to anyone except it is a useful project and we
> mention it in the release notes.
>
> ---------------------------------------------------------------------------
>
> Thomas Hallgren wrote:
>> Marc G. Fournier wrote:
>>
>> >
>> > As Tom (I believe) has stated, and both Bruce/I have said over and
>> > over again ... this is nothing stop'ng a group of ppl starting up a
>> > "bundled postgresql" project, and dedicating their time and effort
>> > into building something up ...
>> >
>> > As Peter has stated, he had thought of this in the past, and felt it
>> > was easier/better for the various OS distributions to do it on their
>> > own ...
>> >
>> > In fact, Linux and FreeBSD *both* already deal with this in their
>> > RPM/ports collections ... and, in fact, on the FreeBSD side, smaller
>> > is better then larger, so that packager maintainers don't hvae to
>> > download a 12Meg file to get a 1Meg port out of it ...
>> >
>> Bruce Momjian wrote:
>>
>> >We are not adverse to someone taking the core db code, adding other
>> >stuff, and making a new super distribution.
>> >
>> >
>> Your customers and many of your contributors would really like to see
>> PostgreSQL become more then just the core backend. A Redhat bundle is
>> great if your'e a Redhat user. If you are on another platform however,
>> it's no good to you. And some bundle from "a group of ppl" or "someone"?
>> No, sorry, that won't cut it either. It's just not the same thing at all.
>>
>> Regards,
>>
>> Thomas Hallgren
>>
>>
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 7: don't forget to increase your free space map settings
>>
>


--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #