On 8/25/2004 11:39 AM, Marc G. Fournier wrote:
On Wed, 25 Aug 2004, Thomas Hallgren wrote:
This project might be perceived as a thirdparty add-on and thus, fail
its purpose. The steering committee must stand behind this officially.
Will you? What's your opinion about the suggestion?
Behind what?
On Wed, 25 Aug 2004, Thomas Hallgren wrote:
For the first category, an inclusion could be possible if the software
has a potential to reach more users and can make the offering more
complete in some respect. If that's not the case, it should be included.
Most software that "sucks royally" will b
Marc G. Fournier wrote:
1. your project must be pgxs compatible.
2. it must be hosted on pgFoundry.
3. it must have automatic regression testing built in (perhaps this
is part of #1).
4. documentation must follow some guidelines so that it is easy to
combine it with other docs.
5. someone must su
On Wed, 25 Aug 2004, Thomas Hallgren wrote:
1. your project must be pgxs compatible.
2. it must be hosted on pgFoundry.
3. it must have automatic regression testing built in (perhaps this is part
of #1).
4. documentation must follow some guidelines so that it is easy to combine it
with other docs
Christopher,
It seems to me that some vital components have already been set up,
considering:
a) pgxs provides a "build environment" to make it easier to add in
"third party extensions" without each of them having to have its
own full PG source tree.
b) PGFoundry is getting set up as a h
Karsten Hilbert wrote:
a) More software can make use of your good name and reputation.
That's rather dangerous, don't you think ? If PostgreSQL
proper (eg the core server) wants to keep its good name it
better make sure it is bundled with "good" "add-ons". And that
would require precisely the addit
On Tue, 24 Aug 2004, Jan Wieck wrote:
I want to get rid of the recommendations-vacuum. I don't care if we
don't pick the ultimately best of everything that way. If there is a
consensus of people who use these things, repeating their recommendation
will seldom be bad advice. Those people have pro
Tom Lane wrote:
Enlarging the core committee by the amount you seem to be thinking of
would transform it into something quite different than it is now
(in particular it would be too large to make decisions effectively,
IMHO).
I can relate to that. Lean and mean is good. So pehaps the core
commi
On Mon, 23 Aug 2004, Thomas Hallgren wrote:
Tom Lane wrote:
Enlarging the core committee by the amount you seem to be thinking of
would transform it into something quite different than it is now
(in particular it would be too large to make decisions effectively,
IMHO).
I can relate to that. Lean a
On Mon, 23 Aug 2004, Thomas Hallgren wrote:
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
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> ... 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.
Enlarging the core committee by the amount you seem to be thin
Quoting Bruce Momjian <[EMAIL PROTECTED]>:
> Thomas Hallgren wrote:
> > Marc,
> > > Since I (and I don't believe anyone else on core) uses Java ...
> > > shouldn't it be up to the developer of the PL/J* modules to do this? We
>
> > > can't weigh which one is better then the other, as we don't u
On Mon, 23 Aug 2004, Joshua D. Drake wrote:
1. Core -- Main database backend -- central approval/rejection
a. plCore -- controls the release/distribution/testing etc.. of the pl
languages
b. contribCore -- products that make it into contrib
ya, its called moving those things not required in co
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 f
Bruce Momjian wrote:
Csaba Nagy wrote:
Hi all,
Bruce, if postgres is not a company and so on, why don't you open up the
core development team to include some of the contributors who would like
to include their product in the main distribution, and have a bundled
product ? Cause a good data base is
Csaba Nagy wrote:
> Hi all,
>
> Bruce, if postgres is not a company and so on, why don't you open up the
> core development team to include some of the contributors who would like
> to include their product in the main distribution, and have a bundled
> product ? Cause a good data base is definite
Hi all,
Bruce, if postgres is not a company and so on, why don't you open up the
core development team to include some of the contributors who would like
to include their product in the main distribution, and have a bundled
product ? Cause a good data base is definitely not made up just by the
cor
On Mon, 23 Aug 2004, Thomas Hallgren wrote:
Again, I'm not trying to offload work from the contributors onto the members
of core. This is about how things are perceived by the PostgreSQL customers.
Of course the contributors must continue to support their products. If they
don't, I'd expect the
Thomas Hallgren wrote:
> Marc,
> > Since I (and I don't believe anyone else on core) uses Java ...
> > shouldn't it be up to the developer of the PL/J* modules to do this? We
> > can't weigh which one is better then the other, as we don't use it ...
> >
> Of course the contributors should suppl
Marc,
Since I (and I don't believe anyone else on core) uses Java ...
shouldn't it be up to the developer of the PL/J* modules to do this? We
can't weigh which one is better then the other, as we don't use it ...
Of course the contributors should supply as much of this material as
possible. Th
On Sun, 22 Aug 2004, Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> writes:
Perhaps I'm a bit to visionary. But I really think you (the core
commitee) need to consider this.
[ looks at Bruce's and Marc's quite independent responses ... ] I think
the core committee has made it perfectly clear
On Sunday 22 August 2004 16:45, you wrote:
> Jim Worke wrote:
> > I don't mean to be rude or anything, but having 3rd-party solution is a
> > scary option for a business enterprise. I know that they're stable and
> > all, but if it's not supported by PostgreSQL themselves (i.e. included in
> > Pos
Jim Worke wrote:
I don't mean to be rude or anything, but having 3rd-party solution is a scary
option for a business enterprise. I know that they're stable and all, but if
it's not supported by PostgreSQL themselves (i.e. included in PostgreSQL as a
whole package), we're afraid that we have to
23 matches
Mail list logo
