Increased company involvement

However, there was a lot of coordination that happened with Fujitsu that
I don't see happening with the current companies involved. Companies
are already duplicating work that is also done by community members or
by other companies.

That is bound to happen no matter what. Look at plJava and plJ. Some
people just feel that their way is better. Some people just don't get
along etc...

That is why we have 80 Linux distributions and a dozen FreeBSD
distributions (can I include MacOSX?).

The big issue is communication. Because the
PostgreSQL code base is common for most of the companies involved, there
has to be coordination in what they are working on and their approaches.

I can see this as an issue but sometimes that community is a hampering
course as well. I recognize the community goals and respect them but in
some things the community can move really slow. From what I can tell
some of this is caused by the no new features rules etc...

In business moving slow can mean death to a project.

Which is why (hate to beat a dead horse) many OSS projects have moved
to 6 month release cycles.

is happening. I realize this is hard for companies because their
efforts are in some ways part of their profitability.

That is true, there are sometimes strategic reasons to not annouce a
project.

profitability require duplication of effort and code collisions? I am
not sure, but if it does, we are in trouble. I am not sure the
community has the resources to resolve that many collisions.

Which is why you are starting to see forks such as Bizgres but it is
also why you are seeing forks go away (Mammoth PostgreSQL).

Second, some developers are being hired from the community to work on
closed-source additions to PostgreSQL. That is fine and great, but one
way to kill PostgreSQL is to hire away its developers. If a commercial
company wanted to hurt us, that is certainly one way they might do it.
Anyway, it is a concern I have. I am hoping community members hired to
do closed-source additions can at least spend some of their time on
community work.

I would think that most of the developers would stipulate that in order
to take the position??? I know Command Prompt would always make sure
that the developer could work on the community stuff.

And finally, we have a few companies working on features that they
eventually want merged back into the PostgreSQL codebase. That is a
very tricky process and usually goes badly unless the company seeks
community involvement from the start, including user interface,
implementation, and coding standards.

I concur with this. We ran into this with plPerl.

Sincerely,

Joshua D. Drake
Command Prompt, Inc.

--
Your PostgreSQL solutions provider, Command Prompt, Inc.
24x7 support - 1.800.492.2240, programming, and consulting
Home of PostgreSQL Replicator, plPHP, plPerlNG and pgPHPToolkit
http://www.commandprompt.com / http://www.postgresql.org

And finally, we have a few companies working on features that they
eventually want merged back into the PostgreSQL codebase. That is a
very tricky process and usually goes badly unless the company seeks
community involvement from the start, including user interface,
implementation, and coding standards.

You might be interested to know that someone is evening wanting to
sponsor some phpPgAdmin development.

Chris

Joshua D. Drake wrote:

However, there was a lot of coordination that happened with Fujitsu that
I don't see happening with the current companies involved. Companies
are already duplicating work that is also done by community members or
by other companies.

That is bound to happen no matter what. Look at plJava and plJ. Some
people just feel that their way is better. Some people just don't get
along etc...

That is why we have 80 Linux distributions and a dozen FreeBSD
distributions (can I include MacOSX?).

Do companies want to write for Blue Hat PostgreSQL and Suza PostgreSQL
because that might be what happens if we don't stay organized? In fact,
it might have be happening already.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Do companies want to write for Blue Hat PostgreSQL and Suza PostgreSQL
because that might be what happens if we don't stay organized? In fact,
it might have be happening already.

Well that depends... If the companies are writing for Pervasive
PostgreSQL I don't think they would have a problem with that ;).

And I do agree with you Bruce, it is happening already -- I don't think
there is any question in that.

Sincerely,

Joshua D. Drake

--
Your PostgreSQL solutions provider, Command Prompt, Inc.
24x7 support - 1.800.492.2240, programming, and consulting
Home of PostgreSQL Replicator, plPHP, plPerlNG and pgPHPToolkit
http://www.commandprompt.com / http://www.postgresql.org

Joshua D. Drake wrote:

Do companies want to write for Blue Hat PostgreSQL and Suza PostgreSQL
because that might be what happens if we don't stay organized? In fact,
it might have be happening already.

Well that depends... If the companies are writing for Pervasive
PostgreSQL I don't think they would have a problem with that ;).

And I do agree with you Bruce, it is happening already -- I don't think
there is any question in that.

Oh, well good I am not seeing phantoms. I have had time to focus on
where we are for the past few days and I am worried about what I see. It
can be great, or it can be a mess, for both us and the companies
involved, and I want to work to make it the former.

The fact is, we now have more and more companies relying on us to be a
success, and that is an added responsibility for us. We can make it
work, but just hoping for it isn't enough --- we have to focus on the
issues early and plan for that success.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Joshua D. Drake wrote:

However, there was a lot of coordination that happened with Fujitsu that
I don't see happening with the current companies involved. Companies
are already duplicating work that is also done by community members or
by other companies.

That is bound to happen no matter what. Look at plJava and plJ. Some
people just feel that their way is better. Some people just don't get
along etc...

Actually, I think that PL/Java versus PL/J is a good example of where
some coordination would have helped a lot.

The short story:
I was between jobs in December 2003 through February the following year.
A lot of work on PL/Java was made during that time. I had no clue that
there was another active project with similar objectives until after my
first fully functional submission to gborg. Had I known, the outcome
would have been different. Today there are ongoing and very active
efforts to collaborate.

The longer story (if anyone is interested):
Before I started PL/Java I informed the community of my intentions (see
hackers thread "pljava revisited"
http://archives.postgresql.org/pgsql-hackers/2003-12/msg00310.php ). I
got a lot of feedback and good advice such as using C instead of C++,
hosting the project at gborg, etc. but nobody told me back then that
there was an active PL/J project. I found traces of that project on
sourceforge but it seemed to have been dead for over a year. At that
time there was no redirect from sourceforge.

Jan Wieck started the thread "PL/Java issues"
http://archives.postgresql.org/pgsql-hackers/2003-12/msg00819.php in
which I made 2 major posts. Nothing in that thread indicated that there
was an ongoing project and I got no reply to my posts. On January the
7th, I made my first submission to gborg.

When I, in mid February, realized that the PL/J project was indeed alive
and active, I wrote the "PL/Java - next step?"
http://archives.postgresql.org/pgsql-hackers/2004-02/msg00713.php where
I outlined possible futures for PL/Java and PL/J. The outcome of that
was that PL/J (Dave Cramer and Laszlo Hornyak) and I had an IRC meeting
where we agreed on some limited collaboration (see "Minutes from Pl/Java
-next step IRC"
http://archives.postgresql.org/pgsql-hackers/2004-03/msg00171.php ).

From that point and until a month or so ago, the active collaboration
between the projects could have been better. Some things did happen
though. Laszlo asked me to publish some PL/Java interfaces in a public
maven repository which I did and we had some discussions. I made an
attempt to have a major sponsor step in and take the lead in a project
aiming to provide a flexible solution where a choice of approach could
be made but the sponsor understandably wanted to wait and see.

Today, we (the PL/Java and PL/J project members) make common efforts to
factor out client tools that indeed can be common to a separate project.
We are also discussing how to make the PostgreSQL user experience as
similar as possible and thus allowing use of PL/Java or PL/J without
changing anything but configuration.

Kind regards,
Thomas Hallgren

Joshua D. Drake wrote:

However, there was a lot of coordination that happened with Fujitsu that
I don't see happening with the current companies involved. Companies
are already duplicating work that is also done by community members or
by other companies.

That is bound to happen no matter what. Look at plJava and plJ. Some
people just feel that their way is better. Some people just don't get
along etc...

Actually, I think that PL/Java versus PL/J is a good example of where
some coordination would have helped a lot.

The short story:
I was between jobs in December 2003 through February the following year.
A lot of work on PL/Java was made during that time. I had no clue that
there was another active project with similar objectives until after my
first fully functional submission to gborg. Had I known, the outcome
would have been different. Today there are ongoing and very active
efforts to collaborate.

The longer story (if anyone is interested):
Before I started PL/Java I informed the community of my intentions (see
hackers thread "pljava revisited"
http://archives.postgresql.org/pgsql-hackers/2003-12/msg00310.php ). I
got a lot of feedback and good advice such as using C instead of C++,
hosting the project at gborg, etc. but nobody told me back then that
there was an active PL/J project. I found traces of that project on
sourceforge but it seemed to have been dead for over a year. At that
time there was no redirect from sourceforge.

Jan Wieck started the thread "PL/Java issues"
http://archives.postgresql.org/pgsql-hackers/2003-12/msg00819.php in
which I made 2 major posts. Nothing in that thread indicated that there
was an ongoing project and I got no reply to my posts. On January the
7th, I made my first submission to gborg.

When I, in mid February, realized that the PL/J project was indeed alive
and active, I wrote the "PL/Java - next step?"
http://archives.postgresql.org/pgsql-hackers/2004-02/msg00713.php where
I outlined possible futures for PL/Java and PL/J. The outcome of that
was that PL/J (Dave Cramer and Laszlo Hornyak) and I had an IRC meeting
where we agreed on some limited collaboration (see "Minutes from Pl/Java
-next step IRC"
http://archives.postgresql.org/pgsql-hackers/2004-03/msg00171.php ).

From that point and until a month or so ago, the active collaboration
between the projects could have been better. Some things did happen
though. Laszlo asked me to publish some PL/Java interfaces in a public
maven repository which I did and we had some discussions. I made an
attempt to have a major sponsor step in and take the lead in a project
aiming to provide a flexible solution where a choice of approach could
be made but the sponsor understandably wanted to wait and see.

Today, we (the PL/Java and PL/J project members) make common efforts to
factor out client tools that indeed can be common to a separate project.
We are also discussing how to make the PostgreSQL user experience as
similar as possible and thus allowing use of PL/Java or PL/J without
changing anything but configuration.

Kind regards,
Thomas Hallgren

On K, 2005-04-27 at 22:21 -0700, Joshua D. Drake wrote:

However, there was a lot of coordination that happened with Fujitsu that
I don't see happening with the current companies involved. Companies
are already duplicating work that is also done by community members or
by other companies.

That is why we have 80 Linux distributions and a dozen FreeBSD
distributions (can I include MacOSX?).

I guess more aprropriate comparison would be to distibution specific
linux kernels, i.e. RedHat linux kernel vs. suse linux kernel v.s.
"vanilla" or "real" :) linux kernel.

The big issue is communication. Because the
PostgreSQL code base is common for most of the companies involved, there
has to be coordination in what they are working on and their approaches.

I can see this as an issue but sometimes that community is a hampering
course as well. I recognize the community goals and respect them but in
some things the community can move really slow. From what I can tell
some of this is caused by the no new features rules etc...

In business moving slow can mean death to a project.

Which is why (hate to beat a dead horse) many OSS projects have moved
to 6 month release cycles.

Well, it is a two-sided thing. On one hand, businesses usually need new
features "yesterday", but on the other hand, business would loose most
of the benefit of getting the feature fast, if it is not included in the
main branch along the road, preferrably in the next official release,
because said business would be dependent of the implementor of his
specific feature for integrating _all_ other new and desirable fetures
of next releas in their specific version of postgres.

is happening. I realize this is hard for companies because their
efforts are in some ways part of their profitability.

That is true, there are sometimes strategic reasons to not annouce a
project.

I can see no strategic advantages for sponsors in not announcing the
project. There may be some small tactical wins for the actual
implementors, but not even tactical wins the sponsors.

There may be some strategic/tactical reasons for sponsors to announce
who they (the sponsors) are, but I can't see any reason not to announce
the project or not to encourage/ask/demand the implementor to do so.

profitability require duplication of effort and code collisions? I am
not sure, but if it does, we are in trouble. I am not sure the
community has the resources to resolve that many collisions.

Which is why you are starting to see forks such as Bizgres but it is
also why you are seeing forks go away (Mammoth PostgreSQL).

At first glance at least, BizGres looks like a community oriented
project and I hope that BizGres will be a testbed/early implementation
of some DataWarehouse features, which will be integrated back to
postgres at first possibility.

But I too expected the discussion to take place on pgsql-hackers, not
some half-hidden mailinglist on pgfoundry. Or at least an announcement
of that mailinglist to be made on pgsql-hachers.

OTOH, there are some things (2PC, recursive queries, ...) which are
discussed on psql-hacker and still are lingering somewhere and are for
various reasons (one of them may be lack of time/money/sponsor-pressure
for the developer) not in the postgres proper yet.

OTOOH, I see that a growing number of companies who might think of
sponsoring PG development are interested in BI/DW and OLAP features in
addition to plain OLTP enchancements.

--
Hannu Krosing <hannu@skype.net>

Hannu Krosing wrote:

Which is why (hate to beat a dead horse) many OSS projects have moved
to 6 month release cycles.

Well, it is a two-sided thing. On one hand, businesses usually need new
features "yesterday", but on the other hand, business would loose most
of the benefit of getting the feature fast, if it is not included in the
main branch along the road, preferrably in the next official release,
because said business would be dependent of the implementor of his
specific feature for integrating _all_ other new and desirable fetures
of next releas in their specific version of postgres.

Yes, you can bet that will happen. You can also bet that the community
release will have 2X more feature additions than any commercial release
that is a version behind unless _huge_ sums of money are thrown at the
commercial release.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Thursday 28 April 2005 01:48, Joshua D. Drake wrote:

Do companies want to write for Blue Hat PostgreSQL and Suza PostgreSQL
because that might be what happens if we don't stay organized? In fact,
it might have be happening already.

Well that depends... If the companies are writing for Pervasive
PostgreSQL I don't think they would have a problem with that ;).

And I do agree with you Bruce, it is happening already -- I don't think
there is any question in that.

ISTM the allure of differentiation and branding is going to be too strong for
us to prevent such things. An easy way to differentiate is to add some
proprietary/unique extension to the main code and then package that up. If
you have to have all your extensions be put into the community version then
lose this advantage over your comptetitors. (Mammoth PostgreSQL/Replicator is
an example of this) The same holds true for branding.... if your Pervasive
you want to sell Pervasive Postgres rather than PostgreSQL because you get to
push your name out there, and get people thinking about your company whenever
they talk about the database.

I think our goal is to encorage companies to push these changes into the core
as much as possible, pointing out things like the advantages community
support brings like ongoing maintainance, support in add-on tools like
pgadmin or phppgadmin, and eliminating the chance that someone else will
submit a similar solution that gets accepted to the community code there by
deprecating the work they have already done.

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

However, there was a lot of coordination that happened

with Fujitsu

that I don't see happening with the current companies involved.
Companies are already duplicating work that is also done by
community members or by other companies.

That is why we have 80 Linux distributions and a dozen FreeBSD
distributions (can I include MacOSX?).

I guess more aprropriate comparison would be to distibution
specific linux kernels, i.e. RedHat linux kernel vs. suse
linux kernel v.s.
"vanilla" or "real" :) linux kernel.

As someone who has been bitten by the RH vs SuSE vs kernel.org kernel
several times over the past couple of weeks, we should *really* try to
avoid this as much as possible. It's a *major* hassle for the end user
if postgresql is no longer the same as postgresql.

Not exactly sure what to do to avoid it, though ;-) Other than encourage
the companies that develop extensions to submit these to the community
distribution and work to get them accepted there...

I can see this as an issue but sometimes that community is

a hampering

course as well. I recognize the community goals and respect

them but

in some things the community can move really slow. From what I can
tell some of this is caused by the no new features rules etc...

In business moving slow can mean death to a project.

Which is why (hate to beat a dead horse) many OSS projects

have moved

to 6 month release cycles.

Well, it is a two-sided thing. On one hand, businesses
usually need new features "yesterday", but on the other hand,
business would loose most of the benefit of getting the
feature fast, if it is not included in the main branch along
the road, preferrably in the next official release, because
said business would be dependent of the implementor of his
specific feature for integrating _all_ other new and
desirable fetures of next releas in their specific version of
postgres.

An example of this might be Powergres - not sure if it was planned to go
into community ever, but it must be a pain to maintain the threaded
version alongside the main one. I guess that's why it's still based on
7.3...

//Magnus

However, there was a lot of coordination that happened with Fujitsu

that

I don't see happening with the current companies involved.

Companies

are already duplicating work that is also done by community members

or

by other companies.

That is bound to happen no matter what. Look at plJava and plJ. Some
people just feel that their way is better. Some people just don't get
along etc...

That is why we have 80 Linux distributions and a dozen FreeBSD
distributions (can I include MacOSX?).

True enough. And coordination, just like other outward-facing
activities, is often inconvenient and easy to forget. But it's
important. I've just left the Board of Directors of the Web Services
Interoperability organization (WS-I). Coordinating the standards
activities of IBM, MS, Sun, Oracle, BEA, Fujitsu, SAP, and 130 others
takes enormous time and care, but it's the only way coop-etors can
function.

And having said that, aggressive businesspeople will move too quickly at
times, or will hide their activities for business reasons. It's a mostly
forgivable sin, IMO.

Second, some developers are being hired from the community to work

on

closed-source additions to PostgreSQL. That is fine and great, but

one

way to kill PostgreSQL is to hire away its developers. If a

commercial

company wanted to hurt us, that is certainly one way they might do

it.

Anyway, it is a concern I have. I am hoping community members hired

to

do closed-source additions can at least spend some of their time on
community work.

I would think that most of the developers would stipulate that in

order

to take the position??? I know Command Prompt would always make sure
that the developer could work on the community stuff.

The same is true for EnterpriseDB.

And finally, we have a few companies working on features that they
eventually want merged back into the PostgreSQL codebase. That is a
very tricky process and usually goes badly unless the company seeks
community involvement from the start, including user interface,
implementation, and coding standards.

I concur with this. We ran into this with plPerl.

The only way to successfully extend PostgreSQL commercially is to
coordinate with the community.

-- Andy

Hannu,

But I too expected the discussion to take place on pgsql-hackers, not
some half-hidden mailinglist on pgfoundry. Or at least an announcement
of that mailinglist to be made on pgsql-hachers.

Yeah, we should announce the mailing list. Actually, I did direct e-mail a
bunch of people (including you) about it and invite them to the mailing list.
So: http://pgfoundry.org/mail/?group_id=1000107

For discussing potential features, though, I'm personally reluctant at this
point to discuss major features until I and my collaborators (example,
newsysviews) have a concrete proposal together. It's far too easy to get
sidetracked into a discussion of minutia and politics on -hackers; by
generating a complete draft spec (at least) on a small mailing list, it's a
lot easier to focus on specific goals and schedules, and discussions on
hackers around detailed proposals tend to be a lot more focused.

--
Josh Berkus
Aglio Database Solutions
San Francisco

Robert Treat wrote:

ISTM the allure of differentiation and branding is going to be too strong for
us to prevent such things. An easy way to differentiate is to add some
proprietary/unique extension to the main code and then package that up. If
you have to have all your extensions be put into the community version then
lose this advantage over your comptetitors. (Mammoth PostgreSQL/Replicator is
an example of this) The same holds true for branding.... if your Pervasive
you want to sell Pervasive Postgres rather than PostgreSQL because you get to
push your name out there, and get people thinking about your company whenever
they talk about the database.

I think our goal is to encorage companies to push these changes into the core
as much as possible, pointing out things like the advantages community
support brings like ongoing maintainance, support in add-on tools like
pgadmin or phppgadmin, and eliminating the chance that someone else will
submit a similar solution that gets accepted to the community code there by
deprecating the work they have already done.

I remember something the president of Great Bridge told me, he said,
"Great Bridge needs PostgreSQL. If Great Bridge dies, PostgreSQL goes
on (as it did), but if PostgreSQL dies, Great Bridge is dead too".

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On N, 2005-04-28 at 20:13 -0700, Josh Berkus wrote:

Hannu,

But I too expected the discussion to take place on pgsql-hackers, not
some half-hidden mailinglist on pgfoundry. Or at least an announcement
of that mailinglist to be made on pgsql-hachers.

Yeah, we should announce the mailing list. Actually, I did direct e-mail a
bunch of people (including you) about it and invite them to the mailing list.

Probably this got lost somewhere on the way.

For discussing potential features, though, I'm personally reluctant at this
point to discuss major features until I and my collaborators (example,
newsysviews) have a concrete proposal together. It's far too easy to get
sidetracked into a discussion of minutia and politics on -hackers; by
generating a complete draft spec (at least) on a small mailing list, it's a
lot easier to focus on specific goals and schedules, and discussions on
hackers around detailed proposals tend to be a lot more focused.

Maybe :) , still not convinced though. There may be some quite
fundamental things we may miss but which could be spotted by wider
audience early on.

--
Hannu Krosing <hannu@skype.net>

I've deliberately let the dust settle slightly on this.

One thing that might help is a more open sponsorship "clearing house".
Example (not meant as a bid, but just to illustrate): the JDBC driver
needs a scanner overhaul - it breaks on dollar quoting and a bunch of
other stuff. I could do that work (as could others, of course) but I
don't have time, unless someone buys some of my professional time.
Someone might want to do just that, but how would they find me?

Regarding the secret code stuff - I predict that it will quickly bite
whoever does it, unless they are extremely lucky.

cheers

andrew

Bruce Momjian wrote:

Andrew Dunstan wrote:

I've deliberately let the dust settle slightly on this.

One thing that might help is a more open sponsorship "clearing house".
Example (not meant as a bid, but just to illustrate): the JDBC driver
needs a scanner overhaul - it breaks on dollar quoting and a bunch of
other stuff. I could do that work (as could others, of course) but I
don't have time, unless someone buys some of my professional time.
Someone might want to do just that, but how would they find me?

Regarding the secret code stuff - I predict that it will quickly bite
whoever does it, unless they are extremely lucky.

Let me add that we really do want these companies to succeed.

For me, it is all a matter of meeting the company's expectations. If a
company wants to add a closed-source feature to PostgreSQL, that's fine,
but if they work on a features and eventually want it integrated into
the main code, I don't want that to fail and have them be disappointed.
The same goes for duplicated effort --- if they don't wnat it to happen,
I want to help them prevent it.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Andrew Dunstan <andrew@dunslane.net> writes:

Regarding the secret code stuff - I predict that it will quickly bite
whoever does it, unless they are extremely lucky.

Yeah. Bruce and I were worrying about this on the phone today.
If a company is doing some work with the intent that it's a proprietary
extension they can sell, no problem --- the BSD license is specifically
intended to let them do that. What's bothering us is the thought that
people are off in corners developing code that they think they are going
to contribute back into the community code base "after it's done". Past
history shows that the odds of getting such things accepted into the PG
community code base are *very* bad if you didn't communicate with the
community from the start of your development process.

We'd like to avoid such unpleasant surprises, but how to get the word
out?

regards, tom lane

On Fri, 29 Apr 2005, Andrew Dunstan wrote:

One thing that might help is a more open sponsorship "clearing house".
Example (not meant as a bid, but just to illustrate): the JDBC driver
needs a scanner overhaul - it breaks on dollar quoting and a bunch of
other stuff. I could do that work (as could others, of course) but I
don't have time, unless someone buys some of my professional time.
Someone might want to do just that, but how would they find me?

I don't think this is a big issue. I don't know of any companies who were
desperate for a feature and willing to throw money at the problem who
couldn't find a developer to take them up on it. Right now this seems to
be a kind of behind the scenes operation that relies heavily on knowing
the right people, but I think most of our sponsor contact points are able
to point sponsors to the right people. Could this process be more open?
Depends on how the sponsor wants to handle it, they probably don't just
want to throw the task out there and see who comes calling, they want an
assurance from someone they trust that the chosen developer is capable.

One thing that definitely would be nice would be to be able to combine
funds from various sponsors for various features. Alone a company can't
spring for it, but by pooling resources it could get done. This is a lot
tougher to coordinate and unless there is a complete spec in place
different sponsors will pull in different directions. Other bounty type
schemes don't seem to produce results, largely from a lack of cash.
(Here's $500 for two weeks of work).

Anyone care to shed some light on how it works now?

Kris Jurka

We'd like to avoid such unpleasant surprises, but how to get the word
out?

More prominent placement of how to contribute would probably help. The
PGF could help with this as well once it is done. Right now it is ether
on how to contribute unless you know where to look.

Right now on the front page when we ask for support we are asking for
people to donate money. We don't need money. We need people. The support
link goes to bandwidth but a great deal of the project is hosted over
many, many servers with many providers. That really isn't as much of an
issue anymore. At least IMHO.

If it were I there would be a big link in bright text (not literally)
that says, "How to contribute" on the front page of the website. This
would go to a page that talks about the different ways to contribute
with contacts for each topic.

Who is head of Documentation?

Who can I talk to about submitting patches?
To libpq
To ECPG
To JDBC
etc....

What is the CVS policy?

Anyway... just some thoughts.

Sincerely,

Joshua D. Drake
Command Prompt, Inc.

On Fri, Apr 29, 2005 at 11:02:51PM -0700, Joshua D. Drake wrote:

Right now on the front page when we ask for support we are asking for
people to donate money. We don't need money. We need people. The support
link goes to bandwidth but a great deal of the project is hosted over
many, many servers with many providers. That really isn't as much of an
issue anymore. At least IMHO.

If money's not an issue anymore, can we get a bigger box to host
pgfoundry on then? :)
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

If money's not an issue anymore, can we get a bigger box to host
pgfoundry on then? :)

It's been done and is in the process of being brought up at a new colo
facility. There is also a backup box being built for failover purposes ;)

Sincerely,

Joshua D. Drake
Command Prompt, Inc.

Anyone interested in pooling funds for features should take a look at
http://people.freebsd.org/~phk/funding.html, which is about a FreeBSD
developer who offered to work full-time on developing some specific
features should enough people donate. Also worthy of mention is
http://www.freebsdfoundation.org/.

I think that for certain key features there's probably a lot of people
who would fork over between $100 and $1000 towards getting a feature
completed. Improved replication might be a good example. Table
partitioning would absolutely be an example. If there was a means for
these people to donate money towards work being done on some feature,
it's very likely that large chunks of development time could be paid for
just from smaller shops, let alone places that can afford to toss $20k
towards the development of something.

On Sat, Apr 30, 2005 at 12:47:45AM -0500, Kris Jurka wrote:

On Fri, 29 Apr 2005, Andrew Dunstan wrote:

One thing that might help is a more open sponsorship "clearing house".
Example (not meant as a bid, but just to illustrate): the JDBC driver
needs a scanner overhaul - it breaks on dollar quoting and a bunch of
other stuff. I could do that work (as could others, of course) but I
don't have time, unless someone buys some of my professional time.
Someone might want to do just that, but how would they find me?

I don't think this is a big issue. I don't know of any companies who were
desperate for a feature and willing to throw money at the problem who
couldn't find a developer to take them up on it. Right now this seems to
be a kind of behind the scenes operation that relies heavily on knowing
the right people, but I think most of our sponsor contact points are able
to point sponsors to the right people. Could this process be more open?
Depends on how the sponsor wants to handle it, they probably don't just
want to throw the task out there and see who comes calling, they want an
assurance from someone they trust that the chosen developer is capable.

One thing that definitely would be nice would be to be able to combine
funds from various sponsors for various features. Alone a company can't
spring for it, but by pooling resources it could get done. This is a lot
tougher to coordinate and unless there is a complete spec in place
different sponsors will pull in different directions. Other bounty type
schemes don't seem to produce results, largely from a lack of cash.
(Here's $500 for two weeks of work).

Anyone care to shed some light on how it works now?

Kris Jurka

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

On Fri, Apr 29, 2005 at 11:21:35PM -0700, Joshua D. Drake wrote:

If money's not an issue anymore, can we get a bigger box to host
pgfoundry on then? :)

It's been done and is in the process of being brought up at a new colo
facility. There is also a backup box being built for failover purposes ;)

Any ETA? I don't mean to harp, but it looks really bad when someone new
to postgresql comes to investigate something and the site is just
crawling.
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

Any ETA? I don't mean to harp, but it looks really bad when someone new
to postgresql comes to investigate something and the site is just
crawling.

Well the backup should come up in a couple of weeks. I know that the new
pgFoundry is being worked on right now. Josh would have a better idea.

Sincerely,

Joshua D. Drake

Anyone interested in pooling funds for features should take a look at
http://people.freebsd.org/~phk/funding.html, which is about a FreeBSD
developer who offered to work full-time on developing some specific
features should enough people donate. Also worthy of mention is
http://www.freebsdfoundation.org/.

This was really a great idea and we (my company) also supported it because
we use freebsd as our primary os. We also use PostgreSQL as our primary db
so it would be more than likely that we would donate money for something
similar with postgresql if either :
a) we can direct the money at one or more specific tasks
or
b) the tasks founded will be related to core postgresql features e.g.
generel performance or other benefits that fits all.

I think that for certain key features there's probably a lot of people
who would fork over between $100 and $1000 towards getting a feature
completed.

Yes - without any promise I would probably be able to raise between $1000
and $3000 in a period of the next 3 months. I would definately try it
and I have multiple customers that have giving their intent on something
like this.

Improved replication might be a good example. Table
partitioning would absolutely be an example. If there was a means for
these people to donate money towards work being done on some feature,
it's very likely that large chunks of development time could be paid for
just from smaller shops, let alone places that can afford to toss $20k
towards the development of something.

I totally agree. In our preference list I would have the following tasks :
1) IOT (Index Ordered Tables)
2) Table partitioning
3) Better multimaster replication framework
4) Extending PostgreSQL's plugin support with additional hooks in the
backend e.g. :
- for adding new tablestore engines (like mysql can)
- for adding callbacks that get's called on transaction
success/failure
using SPI. (e.g. for housekeeping and cleanup)
5) Adding parameter support for NOTIFY / LISTEN

Jim C. Nasby, Database Consultant decibel@decibel.org

Nicolai Petri
COD, catpipe systems - denmark

Ps. sorry for the x-post - should this be moved to advocacy ?

On Sat, 30 Apr 2005, Nicolai Petri (lists) wrote:

We also use PostgreSQL as our primary db so it would be more than likely
that we would donate money for something similar with postgresql if
either :
a) we can direct the money at one or more specific tasks
or
b) the tasks founded will be related to core postgresql features e.g.
generel performance or other benefits that fits all.

The problem is organization. Who decides who gets what money? What about
features that are paid for and worked on and not accepted into the
community codebase? This was something I hoped the PostgreSQL Foundation
http://thepostgresqlfoundation.org/ would step in and do, but we seem much
more focused on advocacy efforts rather than developemnt ones.

Kris Jurka

I read the hackers list all the time, and have for
years, and my company sponsors PG events every few
months, and I would consider myself fairly "plugged
in" to PG, and this is the first I have seen/heard of
the PostgreSQL Foundation
http://thepostgresqlfoundation.org/

Perhaps a little more promotion of it's existance, and
a link from the PG home page would help out. Firebird
has done a great job with their foundation, and there
are two prominent links to it from their home page.

Also, while PG foundation website states "The
PostgreSQL Foundation does not in any way control the
development of the PostgreSQL project" maybe it should
to some extent. The PG Core dev group should be
honorary top level members, and continue working as
they always have. But the PG foundation is their
official contact point. I don't see Tom's or Bruce's
names in the PG foundation member list, which is odd
and disturbing.

One of the problems I feel the PG project has suffered
from over the years is a lack of centralization. This
made coming to PG difficult for new users, because
they would have to go all over the place for info on
different aspects of PG, and nothing looked
consistent. You guys have made huge steps forward in
the last year or two in pulling things together, but
there is still room for improvement.

Take a look at firebird. They provide a pretty
consistent centralized resource for everything from
the main DB engine, to the JDBC driver, to their
foundation. Now granted, they had a lot easier job to
create a centralized resource because they offer so
much less, and much of it was created after the
foundation was created. It's always easier to not let
the genie out of the bottle than try to put it back
in.

Basically, the PG foundation is a good thing, and the
core hackers should be more involved and represented
in it. The foundation should also be made more
prominent and the primary contact point for companies
looking to contribute in any way to PG. I think if
you did this, there would be more company involvment,
more end user small $$ contributions that could be
pooled to go towards development, and less risk of
companies developing features without contacting PG
first.

Later
Rob
--- Kris Jurka <books@ejurka.com> wrote:

On Sat, 30 Apr 2005, Nicolai Petri (lists) wrote:

We also use PostgreSQL as our primary db so it

would be more than likely

that we would donate money for something similar

with postgresql if

either :
a) we can direct the money at one or more

specific tasks

or
b) the tasks founded will be related to core

postgresql features e.g.

generel performance or other benefits that

fits all.

The problem is organization. Who decides who gets
what money? What about
features that are paid for and worked on and not
accepted into the
community codebase? This was something I hoped the
PostgreSQL Foundation
http://thepostgresqlfoundation.org/ would step in
and do, but we seem much
more focused on advocacy efforts rather than
developemnt ones.

Kris Jurka

---------------------------(end of
broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please
send an appropriate
subscribe-nomail command to
majordomo@postgresql.org so that your
message can get through to the mailing list
cleanly

__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Regarding the secret code stuff - I predict that it will quickly bite
whoever does it, unless they are extremely lucky.

Yeah. Bruce and I were worrying about this on the phone today.
If a company is doing some work with the intent that it's a proprietary
extension they can sell, no problem --- the BSD license is specifically
intended to let them do that. What's bothering us is the thought that
people are off in corners developing code that they think they are going
to contribute back into the community code base "after it's done". Past
history shows that the odds of getting such things accepted into the PG
community code base are *very* bad if you didn't communicate with the
community from the start of your development process.

We'd like to avoid such unpleasant surprises, but how to get the word
out?

Well, I received a private email with most of the companies involved as
CC's and many of them have made comments on the issue, so I think we can
say they saw the postings on this topic.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Kris Jurka wrote:

One thing that definitely would be nice would be to be able to combine
funds from various sponsors for various features. Alone a company can't
spring for it, but by pooling resources it could get done. This is a lot
tougher to coordinate and unless there is a complete spec in place
different sponsors will pull in different directions. Other bounty type
schemes don't seem to produce results, largely from a lack of cash.
(Here's $500 for two weeks of work).

Anyone care to shed some light on how it works now?

I can tell you how I have done it. If a company contacts me to add a
feature, I find the person I think is most qualified, check their
availability, and then get them in touch with the donor. In some cases,
I coordinate the work, and actually funnel the money and guarantee that
the developer will be paid. I can do that because I often have an
existing relationship with the funding company and the developer.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

pgman wrote:

Kris Jurka wrote:

One thing that definitely would be nice would be to be able to combine
funds from various sponsors for various features. Alone a company can't
spring for it, but by pooling resources it could get done. This is a lot
tougher to coordinate and unless there is a complete spec in place
different sponsors will pull in different directions. Other bounty type
schemes don't seem to produce results, largely from a lack of cash.
(Here's $500 for two weeks of work).

Anyone care to shed some light on how it works now?

I can tell you how I have done it. If a company contacts me to add a
feature, I find the person I think is most qualified, check their
availability, and then get them in touch with the donor. In some cases,
I coordinate the work, and actually funnel the money and guarantee that
the developer will be paid. I can do that because I often have an
existing relationship with the funding company and the developer.

Also, there has been some discussion that there should be more
centralization. We have thought of that in the past, and many folks
have talked to me and other community members about this.

The thing that limits centralization is that it is critical that any
individual or company feel free to join the community efforts. When
centralization happens, there is often an _in_ and and _out_ group that
is very bad for encouraging new members. Even the core group tries to
do as little as possible as core members, for exactly this reason. We
created core only so we had a limited group that could make quick
decisions and allow confidential discussions with companies or
individuals. We don't want core to steer development anymore than we
want a centralized group to do that, because if we did, the next company
that comes along and wants to enhance PostgreSQL or offer technical
support services will feel they have to get approval/buy-in from the
_in_ group, and that isn't a productive setup. The fact that new
companies getting involved can't find a central authority is a _good_
thing, if you think about it. It means that we have succeeded in
building a community that allows people to join and feel a part right
away, and they don't have to buy-in or play politics to do it.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Quoth jd@commandprompt.com ("Joshua D. Drake"):

If money's not an issue anymore, can we get a bigger box to host
pgfoundry on then? :)

It's been done and is in the process of being brought up at a new colo
facility. There is also a backup box being built for failover purposes
;)

I'd like to shift Slony-I there, when it makes sense; it has been
quite unfortunate how both GBorg and PGFoundry have been separately
offering, um, "less stability than I particularly like."

Growing pains are something I understand; it's just unfortunate...
--
let name="cbbrowne" and tld="gmail.com" in String.concat "@" [name;tld];;
http://linuxfinances.info/info/finances.html
Rules of the Evil Overlord #177. "If a scientist with a beautiful and
unmarried daughter refuses to work for me, I will not hold her
hostage. Instead, I will offer to pay for her future wedding and her
children's college tuition." <http://www.eviloverlord.com/&gt;

A long time ago, in a galaxy far, far away, books@ejurka.com (Kris Jurka) wrote:

On Sat, 30 Apr 2005, Nicolai Petri (lists) wrote:

We also use PostgreSQL as our primary db so it would be more than likely
that we would donate money for something similar with postgresql if
either :
a) we can direct the money at one or more specific tasks
or
b) the tasks founded will be related to core postgresql features e.g.
generel performance or other benefits that fits all.

The problem is organization. Who decides who gets what money? What
about features that are paid for and worked on and not accepted into
the community codebase? This was something I hoped the PostgreSQL
Foundation http://thepostgresqlfoundation.org/ would step in and do,
but we seem much more focused on advocacy efforts rather than
developemnt ones.

If you have a proposal, by all means, bring it up.

I think you have an excellent thought, and that PGF would be an
excellent place to talk about assembling that "organization."

I'm not certain it is necessarily something that PGF should itself do;
there may be conflicts of interest here and there on the matter. (I
think it's not something where details for "each deal" should come to
the members at large; a committee or other subset would seem more
appropriate.)

Bring it up as new business. It may be appropriate for a committee to
be tasked with taking care of organizing this. Or people may be able
to finger an exact person that is particularly appropriate to
coordinate it.

It sounds as though Bruce has been doing this somewhat already; it
could be sensible for a committee to form to review 'applications,'
filtering out duds, passing only the "good ones" on to Bruce so that,
from there, there's not a lot of bureaucracy to deal with.

Turn some arrangement like this into a motion, and it can surely be
discussed.
--
"cbbrowne","@","gmail.com"
http://linuxdatabases.info/info/x.html
You should talk to the DOCTOR.

Martha Stewart called it a Good Thing when decibel@decibel.org ("Jim C. Nasby") wrote:

Anyone interested in pooling funds for features should take a look at
http://people.freebsd.org/~phk/funding.html, which is about a FreeBSD
developer who offered to work full-time on developing some specific
features should enough people donate. Also worthy of mention is
http://www.freebsdfoundation.org/.

I think that for certain key features there's probably a lot of people
who would fork over between $100 and $1000 towards getting a feature
completed. Improved replication might be a good example. Table
partitioning would absolutely be an example. If there was a means for
these people to donate money towards work being done on some feature,
it's very likely that large chunks of development time could be paid for
just from smaller shops, let alone places that can afford to toss $20k
towards the development of something.

Note that money isn't necessarily the most useful thing.

For Slony-I, I can think of three places where specific contributions
of specific efforts could be really valuable, and potentially free up
other peoples' time to do "heavier lifting."

1. Fully scripted test cases.

There are about a dozen scripts that exist now that test for a
number of known conditions, either generally checking to see if
replication is functioning, or trying to exercise particular
bits of functionaly, or verifying that certain bugs are either
present or absent.

There are some tests I'd like to set up but never get time to
script up. Improving the tests that can be _trivially_ run
would be a big help, and would have a general positive effect
on reliability.

2. Documentation

I tried to get someone to write up "how to do PG upgrades using
Slony-I"; wound up essentially writing it myself.

There is plenty of room for "How I Did Foo With ..." with Things
Other Haven't Tried yet. For instance, I haven't tried Slony-I
on cases involving inheritance; a test script and a document on
this would be super.

3. Actually requesting features

There is a small queue of outside-requested features for Slony-I,
but the queue is pretty small. The vast majority of things
queued have come from discussions between about 4 people, all of
whom are writing code for the project.

I daresay I am being totally myopic here, thinking only of "my
project." There lie my priorities, tough luck :-)!

I'd hazard the guess that would-be contributors might be better off
contributing relatively small things like improving documentation or
assisting by providing usefully detailed test cases than they would be
in contributing small sums of money.

It is _really_ not obvious how specks of money can be usefully put
together to get bigger features to happen.

I think a REALLY valuable thing would be if we could get another
person that was pretty expert with the query optimizer. The only way
to do that is to get someone to spend a year fighting with it.
Throwing a thousand dollars at someone here and there isn't likely to
direct them towards that.
--
output = ("cbbrowne" "@" "gmail.com")
http://linuxfinances.info/info/rdbms.html
programmer, n:
A red eyed, mumbling mammal capable of conversing with inanimate
monsters.

On Saturday 30 April 2005 02:02, Joshua D. Drake wrote:

We'd like to avoid such unpleasant surprises, but how to get the word
out?

More prominent placement of how to contribute would probably help. The
PGF could help with this as well once it is done. Right now it is ether
on how to contribute unless you know where to look.

Right now on the front page when we ask for support we are asking for
people to donate money. We don't need money. We need people. The support
link goes to bandwidth but a great deal of the project is hosted over
many, many servers with many providers. That really isn't as much of an
issue anymore. At least IMHO.

At the least we could add a link in there with some info on sponsoring
development.

If it were I there would be a big link in bright text (not literally)
that says, "How to contribute" on the front page of the website. This
would go to a page that talks about the different ways to contribute
with contacts for each topic.

Who is head of Documentation?

Who can I talk to about submitting patches?
To libpq
To ECPG
To JDBC
etc....

What is the CVS policy?

Anyway... just some thoughts.

Some of this sounds like things that should be put together in the devlopers
faq.

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

On Sat, Apr 30, 2005 at 10:37:06AM +0200, Nicolai Petri (lists) wrote:

Anyone interested in pooling funds for features should take a look at
http://people.freebsd.org/~phk/funding.html, which is about a FreeBSD
developer who offered to work full-time on developing some specific
features should enough people donate. Also worthy of mention is
http://www.freebsdfoundation.org/.

This was really a great idea and we (my company) also supported it because
we use freebsd as our primary os. We also use PostgreSQL as our primary db
so it would be more than likely that we would donate money for something
similar with postgresql if either :
a) we can direct the money at one or more specific tasks
or
b) the tasks founded will be related to core postgresql features e.g.
generel performance or other benefits that fits all.

I think that for certain key features there's probably a lot of
people who would fork over between $100 and $1000 towards getting a
feature completed.

Yes - without any promise I would probably be able to raise between
$1000 and $3000 in a period of the next 3 months. I would definately
try it and I have multiple customers that have giving their intent
on something like this.

Great!

Improved replication might be a good example. Table
partitioning would absolutely be an example. If there was a means for
these people to donate money towards work being done on some feature,
it's very likely that large chunks of development time could be paid for
just from smaller shops, let alone places that can afford to toss $20k
towards the development of something.

I totally agree. In our preference list I would have the following tasks :
1) IOT (Index Ordered Tables)

Is this different from CLUSTER?

2) Table partitioning

That'd be nice. It may be part of the bizgres effort, which
underscores the point others have made about this being not exactly
easy to find.

3) Better multimaster replication framework

Slony-2 will be one of these. It depends (I think) on 2PC, which
appears slated for 8.1. :)

4) Extending PostgreSQL's plugin support with additional hooks in the
backend e.g. :
- for adding new tablestore engines (like mysql can)

To some approximation, DBI-Link
http://pgfoundry.org/projects/dbi-link/
does this. Any help with this would be greatly appreciated, as it is
quickly approaching the edge of my skillset.

- for adding callbacks that get's called on transaction
success/failure using SPI. (e.g. for housekeeping and cleanup)

Would this be like an ON COMMIT TRIGGER?

5) Adding parameter support for NOTIFY / LISTEN

What's this for, and what cool stuff could one do with it?

Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778

Remember to vote!

On Saturday 30 April 2005 17:40, David Fetter wrote:

On Sat, Apr 30, 2005 at 10:37:06AM +0200, Nicolai Petri (lists) wrote:

I totally agree. In our preference list I would have the following tasks
: 1) IOT (Index Ordered Tables)

Is this different from CLUSTER?

I think what he is looking for is a table that is maintained in CLUSTERed
order... ie. new inserts will be put in the appropriate place mimicing what
happens with indexes. This has been discussed in the past and has been shot
down before...see archives on pgsql-hackers for past discussions.

4) Extending PostgreSQL's plugin support with additional hooks in the
backend e.g. :
- for adding new tablestore engines (like mysql can)

my$ql's multiple table handlers is about the ugliest hack I have ever seen
inside a database. I mean I used to not like it, but I've been studying it a
little bit lately and now find it absolutly dreadfull. I can't imagine that
we would ever implement a scheme like the one they have used; whatever
advantage people think they can gain from such a setup can probably be
implemented in a cleaner fasion in postgresql assuming it would be an
advantage at all (and some of those features have been dismissed in the past
as well so there's no garauntee)

- for adding callbacks that get's called on transaction
success/failure using SPI. (e.g. for housekeeping and cleanup)

Would this be like an ON COMMIT TRIGGER?

Another idea I have seen shot down on hackers a number of times...

The point of this email being that, I think the general idea probably needs to
be that any coordinated community sponsored development needs to be centered
on picking your favorite items from the TODO list to be worked on rather than
just specifying a list of things you think should be the top priorities. Of
course there is nothing preventing people from getting new items added to the
todo list, but as a general guidline picking items from the todo gets you
halfway home right out of the gate.

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

On Saturday 30 April 2005 06:05, Kris Jurka wrote:

On Sat, 30 Apr 2005, Nicolai Petri (lists) wrote:

We also use PostgreSQL as our primary db so it would be more than likely
that we would donate money for something similar with postgresql if
either :
a) we can direct the money at one or more specific tasks
or
b) the tasks founded will be related to core postgresql features e.g.
generel performance or other benefits that fits all.

The problem is organization. Who decides who gets what money? What about
features that are paid for and worked on and not accepted into the
community codebase? This was something I hoped the PostgreSQL Foundation
http://thepostgresqlfoundation.org/ would step in and do, but we seem much
more focused on advocacy efforts rather than developemnt ones.

We need to get our 501c status out of the way before we can really get
involved in these issues. Once that happens there will certainly be
opportunity to discuss what role we should play in pushing forward
development.

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Just wanted to address a couple of specific items here...

On Saturday 30 April 2005 08:54, Rob Butler wrote:

I read the hackers list all the time, and have for
years, and my company sponsors PG events every few
months, and I would consider myself fairly "plugged
in" to PG, and this is the first I have seen/heard of
the PostgreSQL Foundation
http://thepostgresqlfoundation.org/

We have deliberatly kept it low key and unadvertised, mainly because we feel
that we don't yet have the infrastructure in place to play a more prominant
role. By infrastructure here I am mainly reffering to legal paperwork that
we have filed but are waiting for a response on from the government... all we
can do is wait on that stuff.

Also, while PG foundation website states "The
PostgreSQL Foundation does not in any way control the
development of the PostgreSQL project" maybe it should
to some extent. The PG Core dev group should be
honorary top level members, and continue working as
they always have. But the PG foundation is their
official contact point. I don't see Tom's or Bruce's
names in the PG foundation member list, which is odd
and disturbing.

There has been a lot of discussion on this topic quite a number of times. Let
me assure you that Tom and Bruce have been included on things from the
begining while having been spared getting dragged into the day to day
machinations of things. Since we are primarily focused on advocacy efforts at
this point, this is probably a good way to position things for now.

Basically, the PG foundation is a good thing, and the
core hackers should be more involved and represented
in it.

For the record 3 of the 6 core team members are involved in the foundation. As
for whomever else you would consider a core hacker, the membership includes a
wide number of postgresql's long time contributors and community advocates.
Right now things are being approached on a small scale while we get our ducks
in a row, but once complete you can expect to see things become a little more
visible.

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

On Sat, 30 Apr 2005, Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Regarding the secret code stuff - I predict that it will quickly bite
whoever does it, unless they are extremely lucky.

Yeah. Bruce and I were worrying about this on the phone today.
If a company is doing some work with the intent that it's a proprietary
extension they can sell, no problem --- the BSD license is specifically
intended to let them do that. What's bothering us is the thought that
people are off in corners developing code that they think they are going
to contribute back into the community code base "after it's done". Past
history shows that the odds of getting such things accepted into the PG
community code base are *very* bad if you didn't communicate with the
community from the start of your development process.

We'd like to avoid such unpleasant surprises, but how to get the word
out?

Well, any company that is going to do something like this is going to have
some sort of representative on the lists ... why not write up a short FAQ,
posted once a month to -hackers, explain how we contributions work, and
that any company lookin gdown this direction should contact the list, and
make sure that there is some sort of liason ...

that is by no means the wording I'd suggestion, just the concept ... this
thread will act as a good 'heads up' to those already here, but its
something that needs to be brought up regularly for those 'new to the
lists' ...

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

On Sat, 30 Apr 2005, Jim C. Nasby wrote:

On Fri, Apr 29, 2005 at 11:21:35PM -0700, Joshua D. Drake wrote:

If money's not an issue anymore, can we get a bigger box to host
pgfoundry on then? :)

It's been done and is in the process of being brought up at a new colo
facility. There is also a backup box being built for failover purposes ;)

Any ETA? I don't mean to harp, but it looks really bad when someone new
to postgresql comes to investigate something and the site is just
crawling.

When is the last time you checked it? While waiting for the new server to
be ready, I've moved the site to the new server that just went online this
past week ... its still not a rocket, but its not 'just crawling' either
...

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

-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: Saturday, April 30, 2005 12:04 PM
To: PostgreSQL advocacy
Cc: Kris Jurka; Andrew Dunstan; PostgreSQL-development
Subject: Re: [pgsql-advocacy] [HACKERS] Increased company involvement

[...]
The thing that limits centralization is that it is critical that
any individual or company feel free to join the community efforts.
When centralization happens, there is often an _in_ and and _out_
group that is very bad for encouraging new members.
[...]
We don't want core to steer development anymore than we want a
centralized group to do that, because if we did, the next company
that comes along and wants to enhance PostgreSQL or offer technical
support services will feel they have to get approval/buy-in from
the _in_ group, and that isn't a productive setup. The fact that
new companies getting involved can't find a central authority is a
_good_ thing, if you think about it. It means that we have succeeded
in building a community that allows people to join and feel a part
right away, and they don't have to buy-in or play politics to do it.

Well, you make Postgres sound like a very democratic community, but
I'm afraid this is a fairy tale. Aren't the people who approve
patches exactly the in group that you claim doesn't exist? Aren't
they the people that you need buy-in from to really contribute to
Postgres? The reason I make this point is because I know what a
democratic development community really looks like, and the Boost
community is one such example. That truly *is* democratic, because
decisions are made as a group, and no fixed subset of members has
an overriding veto. The group has moderators, but they exist only
to moderate discussion on the mailing lists. I'm not saying that
it is bad that Postgres is not democratic. Postgres is a totally
different kind of beast than Boost, and probably benefits from
having a few people ultimately decide its fate. But let's call a
spade a spade and not pretend that contributors don't have to get
buy-in from core.

__
David B. Held
Software Engineer/Array Services Group
200 14th Ave. East, Sartell, MN 56377
320.534.3637 320.253.7800 800.752.8129

Jurka,

One thing that definitely would be nice would be to be able to combine
funds from various sponsors for various features.  Alone a company can't
spring for it, but by pooling resources it could get done.  This is a lot
tougher to coordinate and unless there is a complete spec in place
different sponsors will pull in different directions.  Other bounty type
schemes don't seem to produce results, largely from a lack of cash.
(Here's $500 for two weeks of work).

Actually, I talked to Opensoucexperts.com about this ages ago and they set up
an online bounty system for OSS projects in general. I know that other
players in the OSS space have talked about similar things; also companies
like SRA and CMD are willing to act as development $$$ funnels for
multi-party projects.

The problem is organization. Who decides who gets what money? What about
features that are paid for and worked on and not accepted into the
community codebase? This was something I hoped the PostgreSQL Foundation
http://thepostgresqlfoundation.org/ would step in and do, but we seem much
more focused on advocacy efforts rather than developemnt ones.

Unfortunately, pooling funds for development is not something a non-profit can
realistically do in the US without a whole lot of legal/tax help to navigate
US law. Here NPOs are strictly defined as non-commercial. It might make
sense to set up an NPO in another country, such as Australia, where the
regulations on such things are much more liberal. More importantly, the
Foundation is *still* waiting on its NPO paperwork from the IRS, and I really
don't want to do any major fundraising while there's still the possibility we
could be denied.

Well the backup should come up in a couple of weeks. I know that the new
pgFoundry is being worked on right now. Josh would have a better idea.

We ran into a problem installing GForge. I don't know if Tom had time to
work on it over the weekend; if not I'll be tackling it tonight.

--
Josh Berkus
Aglio Database Solutions
San Francisco

Dave Held wrote:

Well, you make Postgres sound like a very democratic community, but
I'm afraid this is a fairy tale. Aren't the people who approve
patches exactly the in group that you claim doesn't exist? Aren't
they the people that you need buy-in from to really contribute to
Postgres? The reason I make this point is because I know what a
democratic development community really looks like, and the Boost
community is one such example. That truly *is* democratic, because
decisions are made as a group, and no fixed subset of members has
an overriding veto. The group has moderators, but they exist only
to moderate discussion on the mailing lists. I'm not saying that
it is bad that Postgres is not democratic. Postgres is a totally
different kind of beast than Boost, and probably benefits from
having a few people ultimately decide its fate. But let's call a
spade a spade and not pretend that contributors don't have to get
buy-in from core.

Really? You have a different perspective than I see. I have seen
patches be accepted that had no core buy-in. We accept patches based on
group feedback, not some closed approval process.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

Dave Held wrote:

Well, you make Postgres sound like a very democratic community, but
I'm afraid this is a fairy tale. Aren't the people who approve
patches exactly the in group that you claim doesn't exist? Aren't
they the people that you need buy-in from to really contribute to
Postgres? The reason I make this point is because I know what a
democratic development community really looks like, and the Boost
community is one such example. That truly *is* democratic, because
decisions are made as a group, and no fixed subset of members has
an overriding veto. The group has moderators, but they exist only
to moderate discussion on the mailing lists. I'm not saying that
it is bad that Postgres is not democratic. Postgres is a totally
different kind of beast than Boost, and probably benefits from
having a few people ultimately decide its fate. But let's call a
spade a spade and not pretend that contributors don't have to get
buy-in from core.

Really? You have a different perspective than I see. I have seen
patches be accepted that had no core buy-in. We accept patches based on
group feedback, not some closed approval process.

Let me also ask for you to provide an example of the behavior you
describe.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Mon, 2 May 2005, Bruce Momjian wrote:

Bruce Momjian wrote:

Dave Held wrote:

Well, you make Postgres sound like a very democratic community, but
I'm afraid this is a fairy tale. Aren't the people who approve
patches exactly the in group that you claim doesn't exist? Aren't
they the people that you need buy-in from to really contribute to
Postgres? The reason I make this point is because I know what a
democratic development community really looks like, and the Boost
community is one such example. That truly *is* democratic, because
decisions are made as a group, and no fixed subset of members has
an overriding veto. The group has moderators, but they exist only
to moderate discussion on the mailing lists. I'm not saying that
it is bad that Postgres is not democratic. Postgres is a totally
different kind of beast than Boost, and probably benefits from
having a few people ultimately decide its fate. But let's call a
spade a spade and not pretend that contributors don't have to get
buy-in from core.

Really? You have a different perspective than I see. I have seen
patches be accepted that had no core buy-in. We accept patches based on
group feedback, not some closed approval process.

Let me also ask for you to provide an example of the behavior you
describe.

How many patches have you "applied" thinking they were good/safe, only to
have Tom jump on top of you and either require changes, or yank them
completely?

As far as code submissions are concerned, Tom has pretty much been "final
arbitrar" (not that I'm against that, I think its required to keep the
code 'clean') ... those with cvs commit privileges are a bit higher on the
totem, but they've already been "through the fire" with Tom, else they
would't have those privileges ...

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

Marc G. Fournier wrote:

On Mon, 2 May 2005, Bruce Momjian wrote:

Bruce Momjian wrote:

Dave Held wrote:

Well, you make Postgres sound like a very democratic community, but
I'm afraid this is a fairy tale. Aren't the people who approve
patches exactly the in group that you claim doesn't exist? Aren't
they the people that you need buy-in from to really contribute to
Postgres? The reason I make this point is because I know what a
democratic development community really looks like, and the Boost
community is one such example. That truly *is* democratic, because
decisions are made as a group, and no fixed subset of members has
an overriding veto. The group has moderators, but they exist only
to moderate discussion on the mailing lists. I'm not saying that
it is bad that Postgres is not democratic. Postgres is a totally
different kind of beast than Boost, and probably benefits from
having a few people ultimately decide its fate. But let's call a
spade a spade and not pretend that contributors don't have to get
buy-in from core.

Really? You have a different perspective than I see. I have seen
patches be accepted that had no core buy-in. We accept patches based on
group feedback, not some closed approval process.

Let me also ask for you to provide an example of the behavior you
describe.

How many patches have you "applied" thinking they were good/safe, only to
have Tom jump on top of you and either require changes, or yank them
completely?

As far as code submissions are concerned, Tom has pretty much been "final
arbitrar" (not that I'm against that, I think its required to keep the
code 'clean') ... those with cvs commit privileges are a bit higher on the
totem, but they've already been "through the fire" with Tom, else they
would't have those privileges ...

Tom can bring up issues, but it is up to the group to decide if those
are valid. Tom has sway only to the exent the group agrees with Tom's
analysis. If someone else made similar observations, they would take
similar weight, as soon as we were sure the person was reliable in their
observations.

Tom gets patches pulled only because his observations are deemed to be
right by the group, not because he is Tom. The same holds for pretty
much anyone else in the group.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

We don't want core to steer development anymore than we want a
centralized group to do that, because if we did, the next company
that comes along and wants to enhance PostgreSQL or offer technical
support services will feel they have to get approval/buy-in from
the _in_ group, and that isn't a productive setup. The fact that
new companies getting involved can't find a central authority is a
_good_ thing, if you think about it. It means that we have succeeded
in building a community that allows people to join and feel a part
right away, and they don't have to buy-in or play politics to do it.

Well, you make Postgres sound like a very democratic community, but
I'm afraid this is a fairy tale. Aren't the people who approve
patches exactly the in group that you claim doesn't exist?

PostgreSQL is more of Democratic Republic than an actual democracy but
they do very well at it.

Any person can bring a patch and submit it, any person in the community
can argue for it and any person can take the time to fix it to the
specifications that core sets forth.

Sincerely,

Joshua D. Drake
Command Prompt,Inc.

--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: Monday, May 02, 2005 12:17 PM
To: PostgreSQL advocacy
Cc: Dave Held; PostgreSQL-development
Subject: Re: [pgsql-advocacy] [HACKERS] Increased company involvement

[...]
Really? You have a different perspective than I see. I have
seen patches be accepted that had no core buy-in. We accept
patches based on group feedback, not some closed approval
process.

Let me also ask for you to provide an example of the behavior you
describe.

Well, I think there's numerous examples where someone suggests some
feature or idea, and Tom or one or two other core developers will
say: "I don't like that idea", and then the proposer will more or
less give up on it because it is clear that it won't go anywhere.
So whether the process gets stopped at the patch submission level
or the feature proposal level isn't really relevant. It seems pretty
clear that a handful of people decide the direction of Postgres,
and everyone else can either contribute to the features that have
been agreed to be acceptable and relevant, or they can fork their
own version.

Just watching the hackers list suggests to me that this is the norm,
rather than the exception. I guess I'm interested to see which
patches have been accepted that the core developers opposed. Now
don't get me wrong. Sometimes there are good technical reasons why
feature A or B can't or shouldn't be added or even developed. And
I don't suggest that patches lacking technical merit should not be
rejected. But sometimes it seems that ideas with undetermined
merit get passed over because of a quick judgement based on
intuition, and only if the proposer actively fights for it for a
while does it get reconsidered.

Of course, it would be quite a bit of work for me to review the
list and compile instances where I think this has occurred, but
only because of the tedium involved to make a minor point...not
because I think I would have difficulty finding evidence. I'm just
saying that as an outsider, if I had a lot of resources to devote
to contributing to Postgres, I would only consider working on
approved TODO items or making sure I more or less had core buy-in
before writing any code. I don't think it would be worth my
time to work on something that non-core users/developers might
like but core hackers don't.

Like I said, that's not necessarily a bad thing. Postgres is a
piece of software with many interacting components, and there
needs to be some coordination to make sure it evolves in a
sensible way. But I think that implies that there must be and
is some de facto centralization of control, whether that is the
published ideology or not.

__
David B. Held
Software Engineer/Array Services Group
200 14th Ave. East, Sartell, MN 56377
320.534.3637 320.253.7800 800.752.8129

Well, I think there's numerous examples where someone suggests some
feature or idea, and Tom or one or two other core developers will
say: "I don't like that idea", and then the proposer will more or
less give up on it because it is clear that it won't go anywhere.

Well I think that is more perception than anything. Sometimes you have
to fight for what you believe in. For example plPHP. I believe plPHP
belongs in core as do some other people. There are members of core
that are for it and against it.

Command Prompt as the submitter needs to make a valid argument to sway
core. We need to present code they would be happy with. We need to
present reasons why.

If you don't do that, then yes I can see why it would feel as if
the proposer was at a loss once someone like Tom writes his opinion.

However Tom isn't the final word, he just happens to have a lot of
weight as anyone within the project of good standing who donates as much
as he does would.

Everything within the community is pretty much done as a vote and there
are things that core really has nothing to do with (like pgFoundry).

Sincerely,

Joshua D. Drake
Command Prompt, Inc.

--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

Joshua D. Drake wrote:

We don't want core to steer development anymore than we want a
centralized group to do that, because if we did, the next company
that comes along and wants to enhance PostgreSQL or offer technical
support services will feel they have to get approval/buy-in from
the _in_ group, and that isn't a productive setup. The fact that
new companies getting involved can't find a central authority is a
_good_ thing, if you think about it. It means that we have succeeded
in building a community that allows people to join and feel a part
right away, and they don't have to buy-in or play politics to do it.

Well, you make Postgres sound like a very democratic community, but
I'm afraid this is a fairy tale. Aren't the people who approve
patches exactly the in group that you claim doesn't exist?

PostgreSQL is more of Democratic Republic than an actual democracy but
they do very well at it.

Any person can bring a patch and submit it, any person in the community
can argue for it and any person can take the time to fix it to the
specifications that core sets forth.

True, but I don't think "core" sets the specifications. Rather, it is
the community that sets them, or agrees to them by not saying anything.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

-----Original Message-----
From: Joshua D. Drake [mailto:jd@commandprompt.com]
Sent: Monday, May 02, 2005 12:33 PM
To: Dave Held
Cc: PostgreSQL-development; PostgreSQL advocacy
Subject: Re: [pgsql-advocacy] [HACKERS] Increased company involvement

[...]
PostgreSQL is more of Democratic Republic than an actual
democracy but they do very well at it.

I buy that. It is probably a fairly accurate description of
the Postgres community. Everyone has a voice, but ultimately,
the "Senate" (i.e.: patch approvers) passes the laws. Where
it differs is that the Senate is not necessarily democratically
elected. ;)

Any person can bring a patch and submit it, any person in the
community can argue for it and any person can take the time to
fix it to the specifications that core sets forth.

Which brings up an important point. The core developers define
the structure in which change can occur. If people think that
Postgres should move in a direction that affects that framework,
they have to convince core to redefine that specification. It's
like writing new laws vs. amending the Constitution. Even though
anyone can draft a bill and submit it to their representative,
it's ultimately Congress that makes the laws. And while public
opinion can ultimately affect the actions of Congress, it is
still a sovereign body. As Bruce himself said, companies that
wish to contribute must not assume that their work will be
integrated into Postgres. The official stance is that there
only needs to be community buy-in, but it seems more realistic
that there needs to be core buy-in as well, at the least because
of the influence that core thinking has on the community itself.
That's not a bad thing per se, but it's definitely something that
contributors should consider.

__
David B. Held
Software Engineer/Array Services Group
200 14th Ave. East, Sartell, MN 56377
320.534.3637 320.253.7800 800.752.8129

Dave Held wrote:

Just watching the hackers list suggests to me that this is the norm,
rather than the exception. I guess I'm interested to see which
patches have been accepted that the core developers opposed. Now
don't get me wrong. Sometimes there are good technical reasons why
feature A or B can't or shouldn't be added or even developed. And
I don't suggest that patches lacking technical merit should not be
rejected. But sometimes it seems that ideas with undetermined
merit get passed over because of a quick judgement based on
intuition, and only if the proposer actively fights for it for a
while does it get reconsidered.

Of course, it would be quite a bit of work for me to review the
list and compile instances where I think this has occurred, but
only because of the tedium involved to make a minor point...not
because I think I would have difficulty finding evidence. I'm just

Well, if there was an issue and you had been around for a minimal amount
of time, I would think you could come up with at least one example.

saying that as an outsider, if I had a lot of resources to devote
to contributing to Postgres, I would only consider working on
approved TODO items or making sure I more or less had core buy-in
before writing any code. I don't think it would be worth my
time to work on something that non-core users/developers might
like but core hackers don't.

Well, our developer's FAQ clearly states you should communicate your
ideas to the hackers list before starting work to be sure you have
_community_ buy-in, rather than core buy-in.

And the TODO list is not a core list, it is accumulated from community
suggestions and discussion.

Like I said, that's not necessarily a bad thing. Postgres is a
piece of software with many interacting components, and there
needs to be some coordination to make sure it evolves in a
sensible way. But I think that implies that there must be and
is some de facto centralization of control, whether that is the
published ideology or not.

I will give you the example of adding a read-only table as an example. I
am betting the idea will not be accepted because the costs outweight the
gain, but I will post my opinions on the list and others will as well
and we will come to some concensus. If X members feel something is bad,
and 5X members think something is good, it almost always gets in --- it
doesn't matter if all the core people are in X or not.

Another example is the recent patch to check if there are orphaned file
system files. That was submitted, Tom had questions, I posted why I
thought it was valid, and the patch is going in today. Anyone has the
ability to argue their point and try to sway the community, and any
member has the right to request a vote on a specific issue.

Perhaps we are more a replublic because we do defer our judgement to
others who have looked into the area more thoroughly.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Any person can bring a patch and submit it, any person in the community
can argue for it and any person can take the time to fix it to the
specifications that core sets forth.

True, but I don't think "core" sets the specifications. Rather, it is
the community that sets them, or agrees to them by not saying anything.

Well I can't concur with that. I can concur that may be what "core"
would want but I don't see that as what it is.

However that could could also be perception as it isn't really that
clear what core does except set the specification.

Sincerely,

Joshua D. Drake
Command Prompt, Inc.

--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

Joshua D. Drake wrote:

Well, I think there's numerous examples where someone suggests some
feature or idea, and Tom or one or two other core developers will
say: "I don't like that idea", and then the proposer will more or
less give up on it because it is clear that it won't go anywhere.

Well I think that is more perception than anything. Sometimes you have
to fight for what you believe in. For example plPHP. I believe plPHP
belongs in core as do some other people. There are members of core
that are for it and against it.

Command Prompt as the submitter needs to make a valid argument to sway
core. We need to present code they would be happy with. We need to
present reasons why.

I think the plan for plphp is to put the source in our CVS, but to
require it to be compiled as a separate 'make' step after php is fully
installed and using the new libpq. I think we had agreement on that
solution.

If you don't do that, then yes I can see why it would feel as if
the proposer was at a loss once someone like Tom writes his opinion.

However Tom isn't the final word, he just happens to have a lot of
weight as anyone within the project of good standing who donates as much
as he does would.

Everything within the community is pretty much done as a vote and there
are things that core really has nothing to do with (like pgFoundry).

Right, the point is that Tom has weight because he is Tom and people
value his opinion, not because he is core.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Mon, 2 May 2005, Bruce Momjian wrote:

Joshua D. Drake wrote:

Well, I think there's numerous examples where someone suggests some
feature or idea, and Tom or one or two other core developers will
say: "I don't like that idea", and then the proposer will more or
less give up on it because it is clear that it won't go anywhere.

Well I think that is more perception than anything. Sometimes you have
to fight for what you believe in. For example plPHP. I believe plPHP
belongs in core as do some other people. There are members of core
that are for it and against it.

Command Prompt as the submitter needs to make a valid argument to sway
core. We need to present code they would be happy with. We need to
present reasons why.

I think the plan for plphp is to put the source in our CVS, but to
require it to be compiled as a separate 'make' step after php is fully
installed and using the new libpq. I think we had agreement on that
solution.

Last I read, both Tom and I were against it being in CVS (albeit for
different reasons) ... and there hadn't been any discussions past the end
of that thread that I've seen ...

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

pgman wrote:

If you don't do that, then yes I can see why it would feel as if
the proposer was at a loss once someone like Tom writes his opinion.

However Tom isn't the final word, he just happens to have a lot of
weight as anyone within the project of good standing who donates as much
as he does would.

Everything within the community is pretty much done as a vote and there
are things that core really has nothing to do with (like pgFoundry).

Right, the point is that Tom has weight because he is Tom and people
value his opinion, not because he is core.

It seems that though discerning observers agree with the above
statement, the perception of new people is that Tom has weight _mostly_
because he is in core.

So, how do we fix this? Do we boot Tom out of core so people can see he
has the same impact? That seems pointless.

(Funny, no one says I have too much power. I will have to look into how
to get some someday.) :-)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Marc G. Fournier wrote:

On Mon, 2 May 2005, Bruce Momjian wrote:

Joshua D. Drake wrote:

Well, I think there's numerous examples where someone suggests some
feature or idea, and Tom or one or two other core developers will
say: "I don't like that idea", and then the proposer will more or
less give up on it because it is clear that it won't go anywhere.

Well I think that is more perception than anything. Sometimes you have
to fight for what you believe in. For example plPHP. I believe plPHP
belongs in core as do some other people. There are members of core
that are for it and against it.

Command Prompt as the submitter needs to make a valid argument to sway
core. We need to present code they would be happy with. We need to
present reasons why.

I think the plan for plphp is to put the source in our CVS, but to
require it to be compiled as a separate 'make' step after php is fully
installed and using the new libpq. I think we had agreement on that
solution.

Last I read, both Tom and I were against it being in CVS (albeit for
different reasons) ... and there hadn't been any discussions past the end
of that thread that I've seen ...

I posted this compromise and no one replied so I thought everyone was OK
with it. It gets it into CVS, but has a separate compile stage to deal
with the recursive dependency problem.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Dave,

 The group has moderators, but they exist only
to moderate discussion on the mailing lists.  I'm not saying that
it is bad that Postgres is not democratic.  Postgres is a totally
different kind of beast than Boost, and probably benefits from
having a few people ultimately decide its fate.  But let's call a
spade a spade and not pretend that contributors don't have to get
buy-in from core.

Hmmm ... why does everyone assume that Core does more than what we do? I
think that most people would be surprised by how *little* traffic there is on
the pgsql-core mailing list.

Core decides on releases, and approves committers. Occasionally we'll handle
something which requires confidentiality, like a security issue or a new
corporate participant.

The committers, who do *not* have exact overlap with Core (for example, Neil
is a committer but not on Core, and I am on Core but not a committer)
actually commit patches, so the participation of *one* of them is required to
get something in to the core code. Materially, what's accepted is decided
through open discussion on the pgsql-hackers list; even Tom brings up his
patches for discussion before commit, and I'd defy you to point to even one
patch which was accepted by consensus on pgsql-hackers and not committed.

As you've already observed, if Tom doesn't like something it's very unlikely
to get through. But that's true for a lot of major contributors; the
consensus process we use provides ample opportunities to veto and slender
opportunities to pass. Go back in the archives to 7.4 development, and you
will see Peter exercising his veto a lot, rather than Tom -- and Peter was
not a Core team member at the time. From my perspective, this is a good
thing for a database system which can get easily broken by an ill-considered
patch. It's *good* for us to be development-conservative.

So there is an "insider group", but it's the group of major contributors. Tom
has the loudest voice because he writes the most code. The fact that Tom,
Bruce or Peter's veto is often as far as a proposal goes is simply because
most of the pgsql-hackers subscribers simply don't involve themselves in the
process unless it's one of their own pet features. And the important thing
about the group of major contributors is that membership is open.

This goes beyond new proposals. Just the other day Bruce was lamenting the
fact that despite having a number of committers, nobody other than him seems
willing to work out the conflicts and get pending patches into acceptable
shape for backend integration -- some patches stayed in the queue for months
while he was out. This is bad; it bottlenecks us and makes Bruce and Tom
the de-facto arbiters of acceptance because they personally have to adjust
and commit submissions.

If people want the acceptance process to be more "democratic", then those
people have to be willing to do the work of full participation. This means
arguing and doing research on the hackers list, even for proposals that don't
personally benefit you; helping debug and/or test patches to get rid of their
problems; and ultimately, becoming a major contributor and then a committer
yourself so that you can take over part of Bruce's workload.

When this system has broken down it's specifically because people on the
-hackers list were lazy or distracted and ignored other people's patch
proposals, allowing one member's (whether Tom or anyone else) reflexive veto
to stand without challenge. And by failing to champion the usefulness of
proposals. I know that some of Joe's proposals were unfairly killed simply
because nobody on -hackers spoke up for them, leading Tom and others to
believe that they weren't popular or needed.

Personally, I tend to think that one of the several things fundamentally
broken in the US electoral system is that there is no relationship between
political participation, voting, and authority. I don't see any reason to
replicate those mistakes with our project. So if your definition of
"democracy" is "everyone has an equal voice regardless of participation
level", then thank the gods we're not a "democracy".

(P.S. on a complete tangent, "call a spade a spade" is actually a racist
expression originating in the reconstruction-era South. "spade" does not
mean garden tool but is a derogatory slang term for black people. It's an
expression I avoid for that reason. I don't expect anyone to have known
this, but now you do.)

--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

On Mon, 2 May 2005, Josh Berkus wrote:

As you've already observed, if Tom doesn't like something it's very unlikely
to get through.

One thing to note on this one ... I've never seen Tom *not* try and help
the submitter to get the code up to spec either ... he's always bent over
backwards to try and help set someone on the right path if the patch
submission warrants it ...

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

On Mon, 2 May 2005, Bruce Momjian wrote:

I posted this compromise and no one replied so I thought everyone was OK
with it. It gets it into CVS, but has a separate compile stage to deal
with the recursive dependency problem.

Then what is the point of having it in CVS? Other then to make are tar
ball bigger?

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

Marc G. Fournier wrote:

On Mon, 2 May 2005, Josh Berkus wrote:

As you've already observed, if Tom doesn't like something it's very
unlikely
to get through.

One thing to note on this one ... I've never seen Tom *not* try and help
the submitter to get the code up to spec either ... he's always bent
over backwards to try and help set someone on the right path if the
patch submission warrants it ...

I would second this. Even when he has disagreed he is always willing to
say why and even offer guidance to sway him.

Sincerely,

Joshua D. Drake
Command Prompt, Inc.

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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

Marc G. Fournier wrote:

On Mon, 2 May 2005, Bruce Momjian wrote:

I posted this compromise and no one replied so I thought everyone was OK
with it. It gets it into CVS, but has a separate compile stage to deal
with the recursive dependency problem.

Then what is the point of having it in CVS? Other then to make are tar
ball bigger?

So it can be maintained with other PL languages as the internal API
changes. This is the same reason ecpg is in our CVS because it is tied
to the grammar.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

-----Original Message-----
From: Josh Berkus [mailto:josh@agliodbs.com]
Sent: Monday, May 02, 2005 1:21 PM
To: Bruce Momjian
Cc: Marc G. Fournier; PostgreSQL advocacy; Dave Held;
PostgreSQL-development
Subject: Re: [pgsql-advocacy] [HACKERS] Decision Process WAS:
Increased
company involvement

[...]
Hmmm ... why does everyone assume that Core does more than
what we do? I think that most people would be surprised by
how *little* traffic there is on the pgsql-core mailing list.

Well, I never said that core runs around saving the world. I
mostly made the point that core developers have special
influence, and that should be considered when contributing to
Postgres, which is directly relevant to the point of the
thread, which was originally called "Increased company
involvement."

Core decides on releases, and approves committers.
Occasionally we'll handle something which requires
confidentiality, like a security issue or a new
corporate participant.

Which is also something that new would-be corporate
contributors should know about.

[...]
Materially, what's accepted is decided through open
discussion on the pgsql-hackers list; even Tom brings
up his patches for discussion before commit, and I'd
defy you to point to even one patch which was accepted
by consensus on pgsql-hackers and not committed.

But this misses the point. The point is that consensus is
often an iterative process, and even if a few people support
an idea at first, in the end, the weight of a few "inner
circle" people (whether they be core or patch approvers
or whatnot) tends to sway the consensus in a certain
direction. This isn't always bad, especially if those
core people simply know more about the internals of
Postgres to have better judgement. It is bad if the person
making the proposal doesn't feel he/she has good odds in
defending the proposal and gives up without a fight.

As you've already observed, if Tom doesn't like something
it's very unlikely to get through. But that's true for
a lot of major contributors; the consensus process we use
provides ample opportunities to veto and slender
opportunities to pass.

This also misses another point. I'm not saying that the
current process is inherently flawed. It's probably about as
good as any OSS project. My point is that it's not *democratic*,
and that outsiders wishing to contribute should understand
the dynamic of the process that is not explicitly and officially
spelled out anywhere.

[...]
From my perspective, this is a good thing for a database
system which can get easily broken by an ill-considered
patch. It's *good* for us to be development-conservative.

Right. I agree. I'm not criticising the process as a whole,
and I've more or less made this exact point myself.

So there is an "insider group", but it's the group of major
contributors.

That is exactly my point, but you said it better.

Tom has the loudest voice because he writes the most code.
The fact that Tom, Bruce or Peter's veto is often as far as
a proposal goes is simply because most of the pgsql-hackers
subscribers simply don't involve themselves in the process
unless it's one of their own pet features.

Which is perfectly understandable. You can probaby guess that
most people who use Postgres haven't tried to implement an
RDBMS themselves, and have only a shallow understanding of the
details.

And the important thing about the group of major contributors
is that membership is open.

Which may be true philosophically, but in practice, most people
who contribute will not have the resources or motivation to
become a major contributor. I do not mean to imply that this
is necessarily a bad thing; but I think it is the true state of
affairs, and part of the dynamic which must be understood by
someone considering investing in Postgres as a contributor.

[...]
If people want the acceptance process to be more "democratic",
then those people have to be willing to do the work of full
participation.

That actually doesn't make it more democratic. In a democracy,
everyone has an equal vote regardless of their status. The point
is that a democracy is not always a priori the best form of
organization. What you describe is actually a meritocracy,
and for a project like Postgres, it makes a lot of sense. But
that merely reinforces my point that contributors need to
understand that if their pet feature they create is not in line
with core thinking, they will have to earn the credibility to
get community buy-in.

[...]
(P.S. on a complete tangent, "call a spade a spade" is
actually a racist expression originating in the
reconstruction-era South. "spade" does not mean garden tool
but is a derogatory slang term for black people.
[...]

Interesting. Duly noted.

__
David B. Held
Software Engineer/Array Services Group
200 14th Ave. East, Sartell, MN 56377
320.534.3637 320.253.7800 800.752.8129

Bruce,

(P.S. on a complete tangent, "call a spade a spade" is actually a racist
expression originating in the reconstruction-era South.   "spade" does

You must be from California.  :-)

Well, yes. Actually, from San Francisco, which is even worse. And I just
spent the weekend in Orange County which really gotten my PC dander up.
Sorry, Dave!

--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

Josh Berkus <josh@agliodbs.com> writes:

As you've already observed, if Tom doesn't like something it's very unlikely
to get through.

I lose my share of arguments --- in fact, in the twenty minutes since
your posting I already notice Bruce committing a patch I had objected to
;-).

Our process is not "democratic" in the sense of any random subscriber to
the mailing lists having the same vote as a core member --- and I'll bet
Boost doesn't run things that way either. What we have is pretty
informal but I think it effectively gives more weight to the opinions of
those more involved in the project; which seems a good way to operate.
But there isn't anyone here who has an absolute veto, nor contrarily
anyone who can force things in unilaterally over strong objections.

[ much good commentary snipped ]

regards, tom lane

On Mon, 2 May 2005, Bruce Momjian wrote:

Marc G. Fournier wrote:

On Mon, 2 May 2005, Bruce Momjian wrote:

I posted this compromise and no one replied so I thought everyone was OK
with it. It gets it into CVS, but has a separate compile stage to deal
with the recursive dependency problem.

Then what is the point of having it in CVS? Other then to make are tar
ball bigger?

So it can be maintained with other PL languages as the internal API
changes. This is the same reason ecpg is in our CVS because it is tied
to the grammar.

Since when? I thought you didn't need the PostgreSQL sources in order to
compile pl/PHP, only the installed headers/libraries ... Joshua, has
something changed, or did I mis-understand that requirement?

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

Marc G. Fournier wrote:

On Mon, 2 May 2005, Bruce Momjian wrote:

Marc G. Fournier wrote:

On Mon, 2 May 2005, Bruce Momjian wrote:

I posted this compromise and no one replied so I thought everyone was OK
with it. It gets it into CVS, but has a separate compile stage to deal
with the recursive dependency problem.

Then what is the point of having it in CVS? Other then to make are tar
ball bigger?

So it can be maintained with other PL languages as the internal API
changes. This is the same reason ecpg is in our CVS because it is tied
to the grammar.

Since when? I thought you didn't need the PostgreSQL sources in order to
compile pl/PHP, only the installed headers/libraries ... Joshua, has
something changed, or did I mis-understand that requirement?

The issue is that we have had to wack around the existing PL languages
for almost every release to make them work with server changes, and
being outside our CVS, plPHP isn't getting that whacking.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Since when? I thought you didn't need the PostgreSQL sources in order
to compile pl/PHP, only the installed headers/libraries ... Joshua, has
something changed, or did I mis-understand that requirement?

Well we don't modify the backend or anything but the way plPHP is
written it assumes it is part of the tree, which is why we have to patch.

However I think part of the argument goes to API. For example the latest
release of plPHP will not work with 7.4.

Sincerely,

Joshua D. Drake

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

--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

On Mon, 2 May 2005, Bruce Momjian wrote:

Marc G. Fournier wrote:

On Mon, 2 May 2005, Bruce Momjian wrote:

Marc G. Fournier wrote:

On Mon, 2 May 2005, Bruce Momjian wrote:

I posted this compromise and no one replied so I thought everyone was OK
with it. It gets it into CVS, but has a separate compile stage to deal
with the recursive dependency problem.

Then what is the point of having it in CVS? Other then to make are tar
ball bigger?

So it can be maintained with other PL languages as the internal API
changes. This is the same reason ecpg is in our CVS because it is tied
to the grammar.

Since when? I thought you didn't need the PostgreSQL sources in order to
compile pl/PHP, only the installed headers/libraries ... Joshua, has
something changed, or did I mis-understand that requirement?

The issue is that we have had to wack around the existing PL languages
for almost every release to make them work with server changes, and
being outside our CVS, plPHP isn't getting that whacking.

And the point is, as Tom has pointed out with tsearch2, that even *in*
CVS, it is a fair amount of work to 'whack' other ppls code ... it
shouldn't be Tom's responsibility (which is generally what it comes down
to) to keep someone else's code up to speed with changes in the server ...

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

The issue is that we have had to wack around the existing PL languages
for almost every release to make them work with server changes, and
being outside our CVS, plPHP isn't getting that whacking.

And the point is, as Tom has pointed out with tsearch2, that even *in*
CVS, it is a fair amount of work to 'whack' other ppls code ... it
shouldn't be Tom's responsibility (which is generally what it comes down
to) to keep someone else's code up to speed with changes in the server ...

Well we try to keep up :)

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

--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

Dave Held wrote:

[...]
(P.S. on a complete tangent, "call a spade a spade" is
actually a racist expression originating in the
reconstruction-era South. "spade" does not mean garden tool
but is a derogatory slang term for black people.
[...]

Interesting. Duly noted.

It would be interesting if it were true. Be careful the urban myths you
accept. See for more info:
http://www.randomhouse.com/wotd/index.pperl?date=19970115

Use of the phrase is unwise these days because of the widespread
misconception about its origin. PC bites us all.

cheers

andrew

"Marc G. Fournier" <scrappy@postgresql.org> writes:

On Mon, 2 May 2005, Bruce Momjian wrote:

Marc G. Fournier wrote:

Then what is the point of having it in CVS? Other then to make are tar
ball bigger?

So it can be maintained with other PL languages as the internal API
changes. This is the same reason ecpg is in our CVS because it is tied
to the grammar.

Since when? I thought you didn't need the PostgreSQL sources in order to
compile pl/PHP, only the installed headers/libraries ... Joshua, has
something changed, or did I mis-understand that requirement?

That could be said of *any* of our PLs (at least now that we install all
server-side headers by default ;-)). I think the real reason we keep
pltcl etc in the core CVS is exactly what Bruce said: it's easier to
maintain 'em that way. The problem is that the PLs use all sorts of
internal backend APIs that we don't want to freeze, and so they are
constantly being affected by changes in the core backend. Just look
at the CVS logs for evidence.

Personally, I'm willing to fix the PLs whenever I make a change that
affects them, but only if they're in core CVS. Dealing with parallel
changes in two different code repositories is too much of a pain.
So the folks maintaining non-core PLs take a big hit every release when
they have to sync with what's happened in the core backend meanwhile.

regards, tom lane

Dave,

Well, I never said that core runs around saving the world. I
mostly made the point that core developers have special
influence,

Yep. Absolutely. I wanted to point out to you that core isn't the only
group within PostgreSQL that has special influence.

Which is also something that new would-be corporate
contributors should know about.

Yes. All of this would be worthy of a FAQ somewhere. Up for it?

It is bad if the person
making the proposal doesn't feel he/she has good odds in
defending the proposal and gives up without a fight.

Yes. Again, I think a FAQ would help. If people are prepared for the idea
of defending their ideas, then they're less likely to quit as soon as someone
says "no".

My point is that it's not *democratic*,
and that outsiders wishing to contribute should understand
the dynamic of the process that is not explicitly and officially
spelled out anywhere.

Hmmm. We'll there's two (or more) uses of the word "democratic"; so I think
there's considerable confusion resulting. In the sense of "democratic"
meaning "maximizing the participation and authority of all project members",
we are "democratic". In the sense of "one person, one vote", we are not.
Classically, our structure could be described as "anarchistic" -- in the
1890's definition, not the modern one.

Right. I agree. I'm not criticising the process as a whole,
and I've more or less made this exact point myself.

Yes. I'm not responding just to you, btw. I'm responding to a number of
comments from other people who erroneously see Core as exercising more
authority than we actually do.

Which may be true philosophically, but in practice, most people
who contribute will not have the resources or motivation to
become a major contributor. I do not mean to imply that this
is necessarily a bad thing; but I think it is the true state of
affairs, and part of the dynamic which must be understood by
someone considering investing in Postgres as a contributor.

Certainly. Although the decision-making process for acceptance is really of
interest primarily for contributors; that is, if you are not submitting, even
by proxy, it shouldn't really matter to you how stuff gets accepted. Except
to the extent that you *should* jump in and advocate for proposals by others
which you like so that the contributors, committers, and core know what
people care about.

That actually doesn't make it more democratic. In a democracy,
everyone has an equal vote regardless of their status. The point
is that a democracy is not always a priori the best form of
organization.

Certainly. See above.

What you describe is actually a meritocracy,
and for a project like Postgres, it makes a lot of sense.

Hmmm ... I dislike the word "meritocracy" because it is applied equally to
corporations, where regardless of merit you're never going to be on the
Board.

But
that merely reinforces my point that contributors need to
understand that if their pet feature they create is not in line
with core thinking, they will have to earn the credibility to
get community buy-in.

Substitute "major contributors" for "core", and you have *my* buy-in.

--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

On Mon, 2 May 2005, Joshua D. Drake wrote:

The issue is that we have had to wack around the existing PL languages
for almost every release to make them work with server changes, and
being outside our CVS, plPHP isn't getting that whacking.

And the point is, as Tom has pointed out with tsearch2, that even *in* CVS,
it is a fair amount of work to 'whack' other ppls code ... it shouldn't be
Tom's responsibility (which is generally what it comes down to) to keep
someone else's code up to speed with changes in the server ...

Well we try to keep up :)

I'm not pointing fingers at you either :) But, you are one of how many
that try and get 'added to core'? How many things do we have in contrib
that the only person that does any 'whacking' is Tom? A couple I've seen
patches go around for, but for a good portion of them, I imagine that they
are 'dead except that Tom keeps fixing them' ...

Tom's focus shouldn't be making sure that everyone's third party add on
"still works" during a release cycle, that should be the responsibility of
the maintainers of those projects, to follow changes and make sure they
are implemented ...

That is what pgFoundry was setup for ... to give projects the visibiilty
they would get through the core distribution by making sure they are
referenced in a central place, but providing the maintainers with direct
CVS access to make changes to their code in a timely manner .. *shrug*

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

I'm not pointing fingers at you either :) But, you are one of how many
that try and get 'added to core'? How many things do we have in contrib
that the only person that does any 'whacking' is Tom? A couple I've
seen patches go around for, but for a good portion of them, I imagine
that they are 'dead except that Tom keeps fixing them' ...

In contrib I would bet a lot. I have argued for the removal of TSearch
(not TSearch2) for example. Also RServ could probably stand to be removed.

However we are not talking about contrib (or at least I am not). We were
talking about PLs which are a little bit of a different beast.

Tom's focus shouldn't be making sure that everyone's third party add on
"still works" during a release cycle, that should be the responsibility
of the maintainers of those projects, to follow changes and make sure
they are implemented ...

I would agree, I suggested test cases for contrib once. I think that
would be very good. If the contrib fails the test case for itself say
after (this could go for pls to) Beta2 then it gets yanked.

That is what pgFoundry was setup for ... to give projects the visibiilty
they would get through the core distribution by making sure they are
referenced in a central place, but providing the maintainers with direct
CVS access to make changes to their code in a timely manner .. *shrug*

It was what pgFoundry was setup for but as I have said elsewhere
perception is everything.

If it isn't in core, it is a second class project. Regardless of how we
all "want" to feel about it.

Sincerely,

Joshua D. Drake
Command Prompt, Inc.

--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

Andrew Dunstan wrote:

I've deliberately let the dust settle slightly on this.

One thing that might help is a more open sponsorship "clearing house".
Example (not meant as a bid, but just to illustrate): the JDBC driver
needs a scanner overhaul - it breaks on dollar quoting and a bunch of
other stuff. I could do that work (as could others, of course) but I
don't have time, unless someone buys some of my professional time.
Someone might want to do just that, but how would they find me?

Regarding the secret code stuff - I predict that it will quickly bite
whoever does it, unless they are extremely lucky.

I like this idea.

There is another issue too. In general, there is a feeling like one
needs to produce something that works and not wait for the slower
movement of the community's approval. I don't think several open source
forks for the project necessarily produce problems if most of these are
used as experimental projects. The example which comes to mind is
Samba-TNG. So some of this concern may be overblown.

This is also the way things work with the SQL Standard: The various
vendors (PostgreSQL included) go out and start with the base, extend
that feature set, and eventually come back together to try to build the
next standard based on everyone's experience. This embrace and extend
process is indeed critical for the further development of the standard.

At the same time, I agree with Bruce's main point-- that the lack of
communication is a threat to this progress. So at least some note of
"Best practices" regarding these extensions or contributions would be a
help. Adding a clearing house to this would also add a critical tool
and would also have the side effect of increasing the pace of
development. Maybe have it divided into two sections: Bids and Bounties.

Best Wishes,
Chris Travers
Metatron Technology Consulting

Josh Berkus wrote:

Dave,

Well, I never said that core runs around saving the world. I
mostly made the point that core developers have special
influence,

Yep. Absolutely. I wanted to point out to you that core isn't the only
group within PostgreSQL that has special influence.

Which is also something that new would-be corporate
contributors should know about.

Yes. All of this would be worthy of a FAQ somewhere. Up for it?

I am working on one based on my original statement that started this
thread. Witht this dicussion, it has move to the top of my TODO list.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Marc G. Fournier wrote:

On Mon, 2 May 2005, Bruce Momjian wrote:

Marc G. Fournier wrote:

On Mon, 2 May 2005, Bruce Momjian wrote:

Marc G. Fournier wrote:

On Mon, 2 May 2005, Bruce Momjian wrote:

I posted this compromise and no one replied so I thought everyone was OK
with it. It gets it into CVS, but has a separate compile stage to deal
with the recursive dependency problem.

Then what is the point of having it in CVS? Other then to make are tar
ball bigger?

So it can be maintained with other PL languages as the internal API
changes. This is the same reason ecpg is in our CVS because it is tied
to the grammar.

Since when? I thought you didn't need the PostgreSQL sources in order to
compile pl/PHP, only the installed headers/libraries ... Joshua, has
something changed, or did I mis-understand that requirement?

The issue is that we have had to wack around the existing PL languages
for almost every release to make them work with server changes, and
being outside our CVS, plPHP isn't getting that whacking.

And the point is, as Tom has pointed out with tsearch2, that even *in*
CVS, it is a fair amount of work to 'whack' other ppls code ... it
shouldn't be Tom's responsibility (which is generally what it comes down
to) to keep someone else's code up to speed with changes in the server ...

When a PL languages is so tied to the changing API that it will only
work for a single major release of PostgreSQL, like ecpg, it is usually
kept in our CVS. This isn't true of odbc, jdbc, or other stuff, and not
even Slony.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

As someone who has made a few minor contributions and plenty of
suggestions, but who is not on the core team, I would like to offer my
observations.

Every suggestion I have ever made that had any merit at all has
eventually worked its way into PostgreSQL (most -- perhaps all -- were
already under consideration).

The dumb ideas I coughed up were neatly shot down in flames as they
should have been.

The PostgreSQL project is very well run, in fact amazingly well
considering the loose structure of an open source project.

There are a few things that might be accomplished a bit differently, but
I do not know how it would be possible to architect it (for instance, I
would completely divorce the testing team from the development team
since that is how it is usually done with commercial systems).

IMO-YMMV.

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-
owner@postgresql.org] On Behalf Of Bruce Momjian
Sent: Monday, May 02, 2005 10:56 AM
To: Dave Held
Cc: PostgreSQL-development; PostgreSQL advocacy
Subject: Re: [pgsql-advocacy] [HACKERS] Increased company involvement

Dave Held wrote:

Just watching the hackers list suggests to me that this is the norm,
rather than the exception. I guess I'm interested to see which
patches have been accepted that the core developers opposed. Now
don't get me wrong. Sometimes there are good technical reasons why
feature A or B can't or shouldn't be added or even developed. And
I don't suggest that patches lacking technical merit should not be
rejected. But sometimes it seems that ideas with undetermined
merit get passed over because of a quick judgement based on
intuition, and only if the proposer actively fights for it for a
while does it get reconsidered.

Of course, it would be quite a bit of work for me to review the
list and compile instances where I think this has occurred, but
only because of the tedium involved to make a minor point...not
because I think I would have difficulty finding evidence. I'm just

Well, if there was an issue and you had been around for a minimal

amount

of time, I would think you could come up with at least one example.

saying that as an outsider, if I had a lot of resources to devote
to contributing to Postgres, I would only consider working on
approved TODO items or making sure I more or less had core buy-in
before writing any code. I don't think it would be worth my
time to work on something that non-core users/developers might
like but core hackers don't.

Well, our developer's FAQ clearly states you should communicate your
ideas to the hackers list before starting work to be sure you have
_community_ buy-in, rather than core buy-in.

And the TODO list is not a core list, it is accumulated from community
suggestions and discussion.

Like I said, that's not necessarily a bad thing. Postgres is a
piece of software with many interacting components, and there
needs to be some coordination to make sure it evolves in a
sensible way. But I think that implies that there must be and
is some de facto centralization of control, whether that is the
published ideology or not.

I will give you the example of adding a read-only table as an example.

I

am betting the idea will not be accepted because the costs outweight

the

gain, but I will post my opinions on the list and others will as well
and we will come to some concensus. If X members feel something is

bad,

and 5X members think something is good, it almost always gets in ---

it

doesn't matter if all the core people are in X or not.

Another example is the recent patch to check if there are orphaned

file

system files. That was submitted, Tom had questions, I posted why I
thought it was valid, and the patch is going in today. Anyone has the
ability to argue their point and try to sway the community, and any
member has the right to request a vote on a specific issue.

Perhaps we are more a replublic because we do defer our judgement to
others who have looked into the area more thoroughly.

--
Bruce Momjian                        |  http://candle.pha.pa.us
pgman@candle.pha.pa.us               |  (610) 359-1001
+  If your life is a hard drive,     |  13 Roberts Road
+  Christ can be your backup.        |  Newtown Square, Pennsylvania
19073

---------------------------(end of

broadcast)---------------------------

TIP 9: the planner will ignore your desire to choose an index scan if

your

Marc G. Fournier wrote:

On Mon, 2 May 2005, Joshua D. Drake wrote:

The issue is that we have had to wack around the existing PL languages
for almost every release to make them work with server changes, and
being outside our CVS, plPHP isn't getting that whacking.

And the point is, as Tom has pointed out with tsearch2, that even *in* CVS,
it is a fair amount of work to 'whack' other ppls code ... it shouldn't be
Tom's responsibility (which is generally what it comes down to) to keep
someone else's code up to speed with changes in the server ...

Well we try to keep up :)

I'm not pointing fingers at you either :) But, you are one of how many
that try and get 'added to core'? How many things do we have in contrib
that the only person that does any 'whacking' is Tom? A couple I've seen
patches go around for, but for a good portion of them, I imagine that they
are 'dead except that Tom keeps fixing them' ...

Tom's focus shouldn't be making sure that everyone's third party add on
"still works" during a release cycle, that should be the responsibility of
the maintainers of those projects, to follow changes and make sure they
are implemented ...

That is what pgFoundry was setup for ... to give projects the visibiilty
they would get through the core distribution by making sure they are
referenced in a central place, but providing the maintainers with direct
CVS access to make changes to their code in a timely manner .. *shrug*

The bottom line is that it is more efficient for one person to adjust
all the PL's at once rather than each PL learning about the changes and
making them.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Monday 02 May 2005 14:49, Josh Berkus wrote:

Bruce,

(P.S. on a complete tangent, "call a spade a spade" is actually a
racist expression originating in the reconstruction-era South.  
"spade" does

You must be from California.  :-)

Well, yes. Actually, from San Francisco, which is even worse. And I
just spent the weekend in Orange County which really gotten my PC dander
up. Sorry, Dave!

And this is why I hate the PC movement... The phrase calling a spade a spade
pre-dates the U.S. as whole, much less the reconstruction-era South. It is
believed to have been introduced into the english language via John Knox in
the 1500's who wrote "I have learned to call wickedness by its own terms: A
fig, a fig, and a spade a spade", borrowing from an earlier latin text, which
is believed to be based on an even earlier Greek writer.

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

On Mon, 2 May 2005, Joshua D. Drake wrote:

I'm not pointing fingers at you either :) But, you are one of how many
that try and get 'added to core'? How many things do we have in contrib
that the only person that does any 'whacking' is Tom? A couple I've seen
patches go around for, but for a good portion of them, I imagine that they
are 'dead except that Tom keeps fixing them' ...

In contrib I would bet a lot. I have argued for the removal of TSearch (not
TSearch2) for example. Also RServ could probably stand to be removed.

rserv was removed long ago ... not sure why tsearch is in there stil
though ...

If it isn't in core, it is a second class project. Regardless of how we
all "want" to feel about it.

As you've seen in the note that I sent to you ... my biggest 'beef'
against continually adding things is the download size just keeps growing,
and when someone already has the core installed, having to redownload it
because they've decided to add something like pl/PHP when pl/PHP doesn't
need anything but the headers/libraries that are already installed seems
idiotic at best ... if some method of extending 'make dist' for the
release cycle can be devised so that pl/PHP (and the other pl/'s would be
nice eventually) tar *with* the core .tar.gz *and* a seperate
plphp-<release>.tar.gz file that can be downloaded seperately, my
arguments against will have been negated ...

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

Marc G. Fournier wrote:

On Mon, 2 May 2005, Joshua D. Drake wrote:

I'm not pointing fingers at you either :) But, you are one of how many
that try and get 'added to core'? How many things do we have in contrib
that the only person that does any 'whacking' is Tom? A couple I've seen
patches go around for, but for a good portion of them, I imagine that they
are 'dead except that Tom keeps fixing them' ...

In contrib I would bet a lot. I have argued for the removal of TSearch (not
TSearch2) for example. Also RServ could probably stand to be removed.

rserv was removed long ago ... not sure why tsearch is in there stil
though ...

Why is dbmirror still there? Can't it be moved to pgfoundry?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tom Lane wrote:

Josh Berkus <josh@agliodbs.com> writes:

As you've already observed, if Tom doesn't like something it's very unlikely
to get through.

I lose my share of arguments --- in fact, in the twenty minutes since
your posting I already notice Bruce committing a patch I had objected to
;-).

I replied to your concerns on Saturday night, and when I saw no
community response by noon today, I assume everyone as OK and applied
it. I suppose this is as good an illustration of the process as we are
going to get.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Mon, 2 May 2005, Bruce Momjian wrote:

Why is dbmirror still there? Can't it be moved to pgfoundry?

Anyone willing to take ownership of it to setup the project itself on
pgfoundry?

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

Marc G. Fournier wrote:

On Mon, 2 May 2005, Bruce Momjian wrote:

Why is dbmirror still there? Can't it be moved to pgfoundry?

Anyone willing to take ownership of it to setup the project itself on
pgfoundry?

I thought it was still maintained?

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

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

Joshua D. Drake wrote:

Marc G. Fournier wrote:

On Mon, 2 May 2005, Bruce Momjian wrote:

Why is dbmirror still there? Can't it be moved to pgfoundry?

Anyone willing to take ownership of it to setup the project itself on
pgfoundry?

I thought it was still maintained?

Right, but it should be moved out of our CVS, I think.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

Joshua D. Drake wrote:

Marc G. Fournier wrote:

On Mon, 2 May 2005, Bruce Momjian wrote:

Why is dbmirror still there? Can't it be moved to pgfoundry?

Anyone willing to take ownership of it to setup the project itself on
pgfoundry?

I thought it was still maintained?

Right, but it should be moved out of our CVS, I think.

We may as well include the mSQL-interface ;) in the removal process.

Sincerely,

Joshua D. Drake

--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

On Mon, 2 May 2005, Bruce Momjian wrote:

Joshua D. Drake wrote:

Marc G. Fournier wrote:

On Mon, 2 May 2005, Bruce Momjian wrote:

Why is dbmirror still there? Can't it be moved to pgfoundry?

Anyone willing to take ownership of it to setup the project itself on
pgfoundry?

I thought it was still maintained?

Right, but it should be moved out of our CVS, I think.

Agreed ... if someone can make the project, I can move the CVS files over
... does anyone know who is currently maintaining it though?

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

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Joshua D. Drake wrote:

Marc G. Fournier wrote:

Anyone willing to take ownership of it to setup the project itself on
pgfoundry?

I thought it was still maintained?

Right, but it should be moved out of our CVS, I think.

Didn't someone offer a rewritten version of dbmirror just this morning?
Maybe that person could be persuaded to run a pgfoundry project.

dbmirror is certainly a fine example of something that doesn't need to
be in the core distro as far as maintenance is concerned. Of course,
it's also not large enough to make much of a difference in tarball size.

regards, tom lane

On Mon, May 02, 2005 at 12:39:27PM -0500, Dave Held wrote:

-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: Monday, May 02, 2005 12:17 PM
To: PostgreSQL advocacy
Cc: Dave Held; PostgreSQL-development
Subject: Re: [pgsql-advocacy] [HACKERS] Increased company involvement

[...]
Really? You have a different perspective than I see. I have
seen patches be accepted that had no core buy-in. We accept
patches based on group feedback, not some closed approval
process.

Let me also ask for you to provide an example of the behavior you
describe.

Well, I think there's numerous examples where someone suggests some
feature or idea, and Tom or one or two other core developers will
say: "I don't like that idea", and then the proposer will more or
less give up on it because it is clear that it won't go anywhere.
So whether the process gets stopped at the patch submission level
or the feature proposal level isn't really relevant. It seems pretty
clear that a handful of people decide the direction of Postgres,
and everyone else can either contribute to the features that have
been agreed to be acceptable and relevant, or they can fork their
own version.

I don't think it's valid to attribute this to the core team at all, but
I do understand what you're saying. Part of this is that many people
like to see data to back up a claim before adding complexity to the
database. The current read-only table discussion is a good example. How
much will it actually help to have a means to reduce the size of
HeapHeaderData? The problem is many times it's very hard to come up with
this data without actually coding something up and trying it. As Josh B.
pointed out in another post, sometimes people will suggest something on
-hackers and it just dies on the vine. This doesn't mean it wouldn't be
useful, it means no one on hackers was interested. But for every user
who's on hackers there's probably 10 than aren't and who knows how many
who might become users if some feature was added.

Personally, I think that the current process could do a better job of
gauging how much user interest there is in changes that are in the gray
area between 'wow, that's a great idea!' and 'wow, that's a horrid
idea!'. There's also the issue of people making suggestions to try and
address a larger problem. I think read-only tables is a good example;
the real issue is that in many data-mining applications the 30 byte
overhead on tuples is huge, and puts postgresql at a big disadvantage.
Read-only tables would definately be difficult to implement, but they
*could* provide a tremendous benefit to PostgreSQL performance in
certain applications. Of course, there's other changes that could also
provide benefits, such as a means to keep a table clustered (or nearly
clustered). But these things have generally been shot-down in the past,
and the data warehousing disadvantage continues.

Now I'm not suggesting that the process is seriously broken, but I do
think that the interests and experiences of the most active developers
tend to keep us away from changes that would only help a subset of users
(or potential users). I also think it would be better if that subset was
heard better. Data warehousing is the current example that comes to
mind, but I'm certain there are others.
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

Marc G. Fournier wrote:

The issue is that we have had to wack around the existing PL languages
for almost every release to make them work with server changes, and
being outside our CVS, plPHP isn't getting that whacking.

And the point is, as Tom has pointed out with tsearch2, that even *in*
CVS, it is a fair amount of work to 'whack' other ppls code ... it
shouldn't be Tom's responsibility (which is generally what it comes
down to) to keep someone else's code up to speed with changes in the
server ...

Just to reiterate a previous point I have made: buildfarm does build
(and mostly test) things in the core. I have *no* plans at all to make
it test things not in core - currently we get code from one source and
it would be a huge effort to change that. I *do* have plans to make it
run the tests for each PL in core, if they are configured in the build.
So be careful about pushing or keeping out of core things that are now
or will soon get buildfarm testing.

The argument about tarball size I can't take seriously - the plperl
directory for example takes 148k uncompressed in a distribution of 72 Mb.

I agree that contrib needs some considerable cleanup. For example, is
there any good reason not to fold in the crypto stuff?

cheers

andrew

Dave Held wrote:

-----Original Message-----
From: Josh Berkus [mailto:josh@agliodbs.com]
Sent: Monday, May 02, 2005 1:21 PM
To: Bruce Momjian
Cc: Marc G. Fournier; PostgreSQL advocacy; Dave Held;
PostgreSQL-development
Subject: Re: [pgsql-advocacy] [HACKERS] Decision Process WAS:
Increased
company involvement

[...]
Hmmm ... why does everyone assume that Core does more than
what we do? I think that most people would be surprised by
how *little* traffic there is on the pgsql-core mailing list.

Well, I never said that core runs around saving the world. I
mostly made the point that core developers have special
influence, and that should be considered when contributing to
Postgres, which is directly relevant to the point of the
thread, which was originally called "Increased company
involvement."

Here is a new FAQ entry:

<H3><A name="1.13">1.13</A>) Who controls PostgreSQL?<BR>

<P>If you are looking for a PostgreSQL gatekeeper, central committee,
or controlling company, give up, because none exists. We do have a
core committee and CVS committers, but these groups are more for
administrative purposes then control. The project is directed by
the open community of developers and users of PostgreSQL. Everyone
is welcome to subscribe and take part in the discussions. (See the
<a href="http://www.postgresql.org/docs/faqs.FAQ_DEV.html&quot;&gt;
Developer's FAQ</A> for information on how to get involved in PostgreSQL
development.)</P>

Adjustments?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Mon, May 02, 2005 at 01:55:50PM -0400, Bruce Momjian wrote:

Dave Held wrote:

Of course, it would be quite a bit of work for me to review the
list and compile instances where I think this has occurred, but
only because of the tedium involved to make a minor point...not
because I think I would have difficulty finding evidence. I'm just

Well, if there was an issue and you had been around for a minimal amount
of time, I would think you could come up with at least one example.

I can help with that. Somebody posted a proposal and patch to shrink
bloated btree indexes. It's a very interesting feature but nobody
replied, so nothing happened.

The 2PC patch by Heikki Linnakangas (sp?) is also waiting and so far I
haven't seen any indication that it may be merged.

This doesn't mean I agree with Dave's argument :-) But there are times
when no major contributor has time to "sponsor" a patch or feature, so
it goes unnoticed and unmerged.

--
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
Voy a acabar con todos los humanos / con los humanos yo acabar�
voy a acabar con todos / con todos los humanos acabar� (Bender)

Marc G. Fournier wrote:

That is what pgFoundry was setup for ... to give projects the visibiilty
they would get through the core distribution by making sure they are
referenced in a central place, but providing the maintainers with direct
CVS access to make changes to their code in a timely manner .. *shrug*

As a user, I think it's not that PGFoundry projects are
second-class projects because of where they live.
I think they're second-class projects because there is
less visibility into the version computability of those
projects with postgresql compared to those in contrib.

Note that this has nothing to do with a project being "part
of core" - it's largely an documentation/organization issue
of pgFoundry itself.

I think a few changes to pgFoundry would make
packages that live there much more viable.

* I'd like to be able to clearly see what version of a given
pgFoundry project works with which PostgreSQL major release.
I'd like this to be consistent among all pgFoundry versions
so I can very quickly and easily find the package I need.

7.3.X 7.4.X 8.0.X nightly_cvs
pgpool:
plhaskel:
[...]

and within that table, I'd want links to source tarballs,
and possibly whatever RPMs, WindowsInstallers, etc work
and have been tested with the given postgresql release.
It's OK for that table to be mostly empty for projects
that have not been tested with many versions, but if
a link is in there there, it'd be a nice way of
knowing if, for example, plFortran works with old
versions (7.3.X) or if it's been ported to the latest
version.

* I'd like to see the status of pgFoundry projects on
http://www.pgbuildfarm.org/cgi-bin/show_status.pl

Right now I have confidence in most of the contrib
modules largely because I can quickly see if they
succeed or fail.

I'd like any pgFoundry project that is released
into the table described above to also have regression
tests that must pass before they're included in that table.
Ideally, I'd like to be able to see those results for
any released PGFoundry projects run on pgbuildfarm as well
so the status is easily visible.

Even if there's no automated testing involved, I think
it'd be nice if that first table existed; and we could
just trust the developers of each project to put the
right tarballs in the right spots in the table. I'm
wildly guessing that this more limited scope should
be a relatively easy first-step in this direction?

I thought it was still maintained?

Right, but it should be moved out of our CVS, I think.

Agreed ... if someone can make the project, I can move the CVS files
over ... does anyone know who is currently maintaining it though?

I can make the project but I obviously have no desire to maintain it.

Sincerely,

Joshua D. Drake

--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

Ron Mayer wrote:

* I'd like to see the status of pgFoundry projects on
http://www.pgbuildfarm.org/cgi-bin/show_status.pl

Right now I have confidence in most of the contrib
modules largely because I can quickly see if they
succeed or fail.

I'd like any pgFoundry project that is released
into the table described above to also have regression
tests that must pass before they're included in that table.
Ideally, I'd like to be able to see those results for
any released PGFoundry projects run on pgbuildfarm as well
so the status is easily visible.

See my cross-posting where I specifically state I have no plans for
buildfarm to test things outside core. It's doable in principle, but
would involve huge amounts of work, for which I at least (as buildfarm's
creator/administrator) would not have time in the foreseeable future.

cheers

andrew

while you weren't looking, Bruce Momjian wrote:

Adjustments?

A couple slight tweaks and rephrasings:

<p>If you're looking for a PostgreSQL gatekeeper, central committe or
controlling company, give up; there isn't one. We do have a core
committe and don't hand out CVS commit privileges like candy, but this
is more for ease of administration than control. The project is driven
by the needs of the community of developers and users, which anyone
can join. All you need to do is subscribe to the mailing list(s) and
participate in the discussions. (See the <a
href="http://www.postgresql.org/faqs.FAQ_DEV.html&quot;&gt;Developer&#39;s FAQ</a>
for more information on how to get involved in PostgreSQL
development.)</p>

/rls

--
:wq

while you weren't looking, I wrote:

[...]

Gah. s/committe/committee/

/rls

--
:wq

On Mon, May 02, 2005 at 04:53:59PM -0400, Andrew Dunstan wrote:

See my cross-posting where I specifically state I have no plans for
buildfarm to test things outside core. It's doable in principle, but
would involve huge amounts of work, for which I at least (as buildfarm's
creator/administrator) would not have time in the foreseeable future.

Would you be open to someone else adding the capability? And maybe
mention that on the buildfarm site? (And before anyone asks, no, this
doesn't interest me enough for me to do it :P)
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

Jim C. Nasby wrote:

On Mon, May 02, 2005 at 04:53:59PM -0400, Andrew Dunstan wrote:

See my cross-posting where I specifically state I have no plans for
buildfarm to test things outside core. It's doable in principle, but
would involve huge amounts of work, for which I at least (as buildfarm's
creator/administrator) would not have time in the foreseeable future.

Would you be open to someone else adding the capability? And maybe
mention that on the buildfarm site? (And before anyone asks, no, this
doesn't interest me enough for me to do it :P)

Of course. I won't hold my breath waiting, though :-)

cheers

andrew

-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: Monday, May 02, 2005 3:33 PM
To: Dave Held
Cc: PostgreSQL advocacy; PostgreSQL-development
Subject: Re: [pgsql-advocacy] [HACKERS] Decision Process WAS:
Increased
company involvement

[...]
Here is a new FAQ entry:

<H3><A name="1.13">1.13</A>) Who controls PostgreSQL?<BR>

<P>If you are looking for a PostgreSQL gatekeeper,
central committee, or controlling company, give up, because
none exists. We do have a core committee and CVS committers,
but these groups are more for administrative purposes then
control. The project is directed by the open community of
developers and users of PostgreSQL. Everyone is welcome to
subscribe and take part in the discussions. (See the
<a href="http://www.postgresql.org/docs/faqs.FAQ_DEV.html&quot;&gt;
Developer's FAQ</A> for information on how to get
involved in PostgreSQL development.)</P>

Adjustments?

"...are more for administrative purposes [then->than] control..."

<p>Because PostgreSQL is a monolithic product, all of its features
must work together in tight harmony. It is in the interests of
the PostgreSQL community that new features be integrated in a way
that preserves this harmony. Thus, new feature proposals are
scrutinized and debated by the community to ensure that changes
have sufficient technical merit. Be prepared to defend your
proposal, and don't assume that a privately developed contribution
will automatically be accepted by the PostgreSQL community. To
maximize the chance of success in proposing a change, consider
these suggestions:

* Propose your change/feature publicly - OSS is about community,
and a collection of contributors working independently without
communication is not a community; this avoids duplication of
effort and promotes collaboration/cooperation among parties
that have a common interest
* Research your proposal to see if it has already been discussed
on the mailing list
* Research your proposed solution to make sure it is the best of
breed - database technology is a very active subject of
academic research, and it is possible, if not likely, that
someone has written a paper on the topic
* Engage the community by participating in discussions and patch
reviews - your credibility as a contributor depends on your
willingness to contribute to the community in non-coding
ways as well
</p>

I realize that this runs a bit far afield from the original
question of "Who controls PostgreSQL?", but I think it addresses
the points that someone who asks this question is likely to
want to know. It also tackles the contribution question from
a higher level than the dev-faq. Obviously, the bullet points
would be formatted as a list or some other appropriate HTML
construct. And as a minor point, it would be nice if the
website validated to XHTML-strict, although XHTML-transitional
would be a good compromise.

__
David B. Held
Software Engineer/Array Services Group
200 14th Ave. East, Sartell, MN 56377
320.534.3637 320.253.7800 800.752.8129

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Monday, May 02, 2005 1:50 PM
To: josh@agliodbs.com
Cc: Bruce Momjian; Marc G. Fournier; PostgreSQL advocacy; Dave Held;
PostgreSQL-development
Subject: Re: [pgsql-advocacy] [HACKERS] Decision Process WAS:
Increased
company involvement

[...]
Our process is not "democratic" in the sense of any random
subscriber to the mailing lists having the same vote as a
core member --- and I'll bet Boost doesn't run things that
way either.

Actually, it does, but it can afford to for very special reasons.
Because Boost is not about a single problem domain, there is no
real "core" of developers. There are some who have contributed
more libraries, or larger libraries; but at the end of the day,
each review and submission is judged on its own merits. Often,
the person submitting a new library for review is a domain expert
for that library; and people reviewing a library are also often
domain experts, even if they are a first-time reviewer. So the
very nature of Boost allows it to be more democratic. Because
Postgres is about a single problem domain, and because each
submission must work in concert with an extant whole, it has
totally different needs and a totally different type of community.
And because a database isn't exactly a modular beast like, say,
a web server, that limits the openness of the community further.
That is to say, there is a barrier to entry, but it isn't
capriciously imposed by the community members. It's just a
necessary outcome of the nature of the project. People who
want to contribute should understand this barrier and how it
works before they start writing code.

What we have is pretty informal but I think it effectively
gives more weight to the opinions of those more involved in
the project; which seems a good way to operate.

For Postgres, I agree.

But there isn't anyone here who has an absolute veto, nor
contrarily anyone who can force things in unilaterally over
strong objections.

Nor would one expect such a thing in a project that claims to
be OSS. But ultimately persuasion is as much a part of
consensus as merit, and people should recognize that fact
when contributing to the project.

__
David B. Held
Software Engineer/Array Services Group
200 14th Ave. East, Sartell, MN 56377
320.534.3637 320.253.7800 800.752.8129

On Monday 02 May 2005 17:32, Dave Held wrote:

-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: Monday, May 02, 2005 3:33 PM
To: Dave Held
Cc: PostgreSQL advocacy; PostgreSQL-development
Subject: Re: [pgsql-advocacy] [HACKERS] Decision Process WAS:
Increased
company involvement

[...]
Here is a new FAQ entry:

<H3><A name="1.13">1.13</A>) Who controls PostgreSQL?<BR>

<P>If you are looking for a PostgreSQL gatekeeper,
central committee, or controlling company, give up, because
none exists. We do have a core committee and CVS committers,
but these groups are more for administrative purposes then
control. The project is directed by the open community of
developers and users of PostgreSQL. Everyone is welcome to
subscribe and take part in the discussions. (See the
<a href="http://www.postgresql.org/docs/faqs.FAQ_DEV.html&quot;&gt;
Developer's FAQ</A> for information on how to get
involved in PostgreSQL development.)</P>

Adjustments?

"...are more for administrative purposes [then->than] control..."

<p>Because PostgreSQL is a monolithic product, all of its features
must work together in tight harmony. It is in the interests of
the PostgreSQL community that new features be integrated in a way
that preserves this harmony. Thus, new feature proposals are
scrutinized and debated by the community to ensure that changes
have sufficient technical merit. Be prepared to defend your
proposal, and don't assume that a privately developed contribution
will automatically be accepted by the PostgreSQL community. To
maximize the chance of success in proposing a change, consider
these suggestions:

* Propose your change/feature publicly - OSS is about community,
and a collection of contributors working independently without
communication is not a community; this avoids duplication of
effort and promotes collaboration/cooperation among parties
that have a common interest
* Research your proposal to see if it has already been discussed
on the mailing list
* Research your proposed solution to make sure it is the best of
breed - database technology is a very active subject of
academic research, and it is possible, if not likely, that
someone has written a paper on the topic
* Engage the community by participating in discussions and patch
reviews - your credibility as a contributor depends on your
willingness to contribute to the community in non-coding
ways as well
</p>

I realize that this runs a bit far afield from the original
question of "Who controls PostgreSQL?", but I think it addresses
the points that someone who asks this question is likely to
want to know. It also tackles the contribution question from
a higher level than the dev-faq.

Actually I think Bruces blurb is good for the general FAQ, and this would be
good for the Developer FAQs

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Robert Treat said:

* Engage the community by participating in discussions and patch
reviews - your credibility as a contributor depends on your
willingness to contribute to the community in non-coding
ways as well

Actually I think Bruces blurb is good for the general FAQ, and this
would be good for the Developer FAQs

I nat happy avout that last point - personally, I value most highly the
views of those who contribute code or similar and least highly the views of
those whose principal contribution is opinions.

cheers

andrew

Marc G. Fournier wrote:

Agreed ... if someone can make the project, I can move the CVS files
over ... does anyone know who is currently maintaining it though?

A little research would reveal:

% head contrib/dbmirror/README.dbmirror
DBMirror - PostgreSQL Database Mirroring
===================================================

DBMirror is a database mirroring system developed for the PostgreSQL
database Written and maintained by Steven Singer(ssinger@navtechinc.com)

(ssinger does submit patches for it on a reasonably regular basis.)

-Neil

Another example is the recent patch to check if there are orphaned file
system files. That was submitted, Tom had questions, I posted why I
thought it was valid, and the patch is going in today. Anyone has the
ability to argue their point and try to sway the community, and any
member has the right to request a vote on a specific issue.

I know so maintainig of PostgreSQL isn't easy. And it's normal so
everybody wont to see commit of your patch. The comunication with core
developers is best, but some times I have opinion so some patches are
lost - for example my little patch SQLSTATE, .. I remeber situation one
year ago with named params of plpgsql function. Patch waited half of year.

I don't wont to be negative :-)). PostgreSQL did big progress. Really. And
last modification of plpgsql helped my in work. But its human natural. I
looking for others nows. I am expectant for 2PC, hiearch queries, and ...
PostgreSQL isn't only sw for me, it's more like idol :-)

Best Regards,
Pavel Stehule

Bruce Momjian wrote:

(Funny, no one says I have too much power. I will have to look into how
to get some someday.) :-)

I think you have power, too. :-) You have commited many patches that some
other commiters didn't like that much and would rather not have applied
themselves. All with some consensus from the community, of course.

The reason, IMHO, that Tom is seen as someone with more power than others,
is because of his intimate knowledge of postgresql and software design in
general. Most of his proposals are very welcome to the community and nobody
would be against those. And if there are objections, Tom will usually listen
to valid criticism and adapt his work.

Not all core members or regular patch submitters have agreed with all
changes in the past, not even within this "in"-group. There are different
opinions and it's not one who always "wins". I believe there is quite a
balance.

For many changes and patches proposed, most of the rejections I have seen
were based on lack of knowledge of either postgresql design or philosophy or
bad software design in general. Of course its rather the "in"-group who
defined the postgresql design and philosophy in the first place, but well,
it is because of them that postgresql exists as what it is.

Most of the hassles can be avoided by speaking up on hackers first and
convince some one with good postgresql know-how to help you get your work on
track.

Best Regards,
Michael Paesold

Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian:

I posted this compromise and no one replied so I thought everyone was OK
with it. It gets it into CVS, but has a separate compile stage to deal
with the recursive dependency problem.

How will a "separate compile stage" work for actually building, say, RPM or
Debian packages? The only way I can see is wrapping up the PostgreSQL
distribution tarball a second time as a "plphp" source package and build from
there, which seems quite weird.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

* Peter Eisentraut (peter_e@gmx.net) wrote:

Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian:

I posted this compromise and no one replied so I thought everyone was OK
with it. It gets it into CVS, but has a separate compile stage to deal
with the recursive dependency problem.

How will a "separate compile stage" work for actually building, say, RPM or
Debian packages? The only way I can see is wrapping up the PostgreSQL
distribution tarball a second time as a "plphp" source package and build from
there, which seems quite weird.

More than a little ugly, no thanks, please don't...

It should really be made to be buildable outside of the PostgreSQL
source tree, depending only upon the server API (which is provided in a
seperate Debian package which plphp could build-depend on). This is
exactly how Slony will be packaged too.. From what I've gathered it
sounds like the only issue with this is that it may not get updated when
the server API changes? Are there other issues? Is there something it
needs that isn't or can't be provided by a seperate server API package?

(For those curious- my current plans are that slony will actually
generate a couple differnet binary debs, slon, slonik and
libpostgresql-slon or so. libpostgresql-slon will have the .so which is
installed in the postgresql libdir, slon and slonik have their
associated programs and supporting things (.sql scripts, etc)).

Thanks,

Stephen

Peter Eisentraut <peter_e@gmx.net> writes:

Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian:

I posted this compromise and no one replied so I thought everyone was OK
with it. It gets it into CVS, but has a separate compile stage to deal
with the recursive dependency problem.

How will a "separate compile stage" work for actually building, say, RPM or
Debian packages? The only way I can see is wrapping up the PostgreSQL
distribution tarball a second time as a "plphp" source package and build from
there, which seems quite weird.

I think the idea is that plphp would be in our CVS, but would not be
shipped as part of the main tarball, rather as its own separate tarball.

regards, tom lane

Stephen Frost wrote:

* Peter Eisentraut (peter_e@gmx.net) wrote:

Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian:

I posted this compromise and no one replied so I thought everyone was OK
with it. It gets it into CVS, but has a separate compile stage to deal
with the recursive dependency problem.

How will a "separate compile stage" work for actually building, say, RPM or
Debian packages? The only way I can see is wrapping up the PostgreSQL
distribution tarball a second time as a "plphp" source package and build from
there, which seems quite weird.

More than a little ugly, no thanks, please don't...

Not really that ugly. It is just an extra compile step. Besides
you don't have to package it just because it is in the Tarball.

Sincerely,

Joshua D. Drake
Command Prompt, Inc.

On Tue, 3 May 2005, Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian:

I posted this compromise and no one replied so I thought everyone was OK
with it. It gets it into CVS, but has a separate compile stage to deal
with the recursive dependency problem.

How will a "separate compile stage" work for actually building, say, RPM or
Debian packages? The only way I can see is wrapping up the PostgreSQL
distribution tarball a second time as a "plphp" source package and build from
there, which seems quite weird.

I think the idea is that plphp would be in our CVS, but would not be
shipped as part of the main tarball, rather as its own separate tarball.

That is what I'm hoping for ... if it can be shipped as a seperate
tarball, my arguments *against* including it become moot, since packagers
(and ports) can have a nice small, quick to download package instead of
having to re-download a >11MB file each time ...

I don't mind if its *also* ship'd in the main distribution as well, I just
want that 'quick to download since I already have the libraries/headers
installed' package ...

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

-----Original Message-----
From: Andrew Dunstan [mailto:andrew@dunslane.net]
Sent: Monday, May 02, 2005 7:05 PM
To: xzilla@users.sourceforge.net
Cc: Dave Held; pgsql-advocacy@postgresql.org;
pgsql-hackers@postgresql.org
Subject: Re: [pgsql-advocacy] [HACKERS] Decision Process WAS:
Increased
company involvement

[...]
I nat happy avout that last point - personally, I value most
highly the views of those who contribute code or similar and
least highly the views of those whose principal contribution
is opinions.

Maybe so, but if you were a new contributor, why would you write
a bunch of code with no assurance that it would go anywhere?
It seems wiser to invest your time familiarizing yourself with
the ins and outs of the codebase and the coding style of patches
by looking at other people's work. It also seems smarter to
lurk and see what kinds of changes are likely to be considered.
I doubt you would think highly of a newcomer that contributed
code that was not in the style of the codebase and was for a
feature not on the TODO list and that didn't get community buy-in
first. But then, how do you get community buy-in if you don't
contribute code, according to you?

__
David B. Held
Software Engineer/Array Services Group
200 14th Ave. East, Sartell, MN 56377
320.534.3637 320.253.7800 800.752.8129

Joshua D. Drake wrote:

Not really that ugly. It is just an extra compile step. Besides
you don't have to package it just because it is in the Tarball.

Since you keep raising that point: Not packaging something is not a
valid solution to something being hard to package.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Marc G. Fournier wrote:

On Tue, 3 May 2005, Tom Lane wrote:

I think the idea is that plphp would be in our CVS, but would not be
shipped as part of the main tarball, rather as its own separate tarball.

That is what I'm hoping for ... if it can be shipped as a seperate
tarball, my arguments *against* including it become moot, since
packagers (and ports) can have a nice small, quick to download package
instead of having to re-download a >11MB file each time ...

I don't mind if its *also* ship'd in the main distribution as well, I
just want that 'quick to download since I already have the
libraries/headers installed' package ...

Any other PL's not currently in your CVS that you might consider to
bring in while you're at it?

Regards,
Thomas Hallgren

Peter Eisentraut wrote:

Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian:

I posted this compromise and no one replied so I thought everyone was OK
with it. It gets it into CVS, but has a separate compile stage to deal
with the recursive dependency problem.

How will a "separate compile stage" work for actually building, say, RPM or
Debian packages? The only way I can see is wrapping up the PostgreSQL
distribution tarball a second time as a "plphp" source package and build from
there, which seems quite weird.

Well like many rpms it will have an external dependency. You must have
perl installed to install plPerl. The main problem here is that you
would need a base install of php at a minimum.

The PHP installed would not need to support PostgreSQL at the time. In
fact now that I think about it depending on how you did it, this doesn't
effect PostgreSQl as much as it effects PHP.

You could compile and install plPHP+PostgreSQL as long as PHP was
installed regardless of the extensions that PHP supported at the time.
So you wouldn't need to compile PostgreSQL twice but you may need to
compile PHP twice. Once for plPHP and then once if you wanted PostgreSQL
support.

Sincerely,

Joshua D. Drake
Command Prompt, Inc.

--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

On Tue, 2005-05-03 at 12:40, Peter Eisentraut wrote:

Joshua D. Drake wrote:

Not really that ugly. It is just an extra compile step. Besides
you don't have to package it just because it is in the Tarball.

Since you keep raising that point: Not packaging something is not a
valid solution to something being hard to package.

Is telling the rpm maintainers to go fix their rpm's an option? As has
been hashed out before, the only thing that makes plphp different from
other pl's is that some of the current packagers are taking shortcuts
with the packaging scripts which introduces dependency issues. IMHO what
is included in the postgresql cvs and what is included in the main
tarball for postgresql should not be dictated by outside packagers.

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

I don't mind if its *also* ship'd in the main distribution as well, I
just want that 'quick to download since I already have the
libraries/headers installed' package ...

We could break out all of the pls at that point? Where if you downloaded
postgresql-opt you would get plPHP, plPerl etc...

Sincerely,

Joshua D. Drake

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

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

On Tue, 3 May 2005, Thomas Hallgren wrote:

Marc G. Fournier wrote:

On Tue, 3 May 2005, Tom Lane wrote:

I think the idea is that plphp would be in our CVS, but would not be
shipped as part of the main tarball, rather as its own separate tarball.

That is what I'm hoping for ... if it can be shipped as a seperate tarball,
my arguments *against* including it become moot, since packagers (and
ports) can have a nice small, quick to download package instead of having
to re-download a >11MB file each time ...

I don't mind if its *also* ship'd in the main distribution as well, I just
want that 'quick to download since I already have the libraries/headers
installed' package ...

Any other PL's not currently in your CVS that you might consider to bring in
while you're at it?

Personally, if the above condition can be met, my objections for inclusion
of anything into core would pretty much be voided, since it eliminates the
requirement to download a 'monster tar ball' if you don't have to ...

That doesn't say anyone else would have objections, only that I wouldn't
...

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

Peter Eisentraut wrote:

Joshua D. Drake wrote:

Not really that ugly. It is just an extra compile step. Besides
you don't have to package it just because it is in the Tarball.

Since you keep raising that point: Not packaging something is not a
valid solution to something being hard to package.

Except that I don't consider it difficult. I do it all the time, it can
be easily scripted.

Sincerely,

Joshua D. Drake

--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

I don't mind if its *also* ship'd in the main distribution as well, I
just want that 'quick to download since I already have the
libraries/headers installed' package ...

Any other PL's not currently in your CVS that you might consider to
bring in while you're at it?

/me heres the sound of the plJava trumpets :)

Regards,
Thomas Hallgren

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

On Tue, 3 May 2005, Joshua D. Drake wrote:

I don't mind if its *also* ship'd in the main distribution as well, I just
want that 'quick to download since I already have the libraries/headers
installed' package ...

We could break out all of the pls at that point? Where if you downloaded
postgresql-opt you would get plPHP, plPerl etc...

Optimally, you would get rid of -opt altogether, and leave it as the
individual pl(s) ... the main purposes of the smaller tar balls is so that
someone building a port (*BSDs) or a package (other OSs) would only need
to download the component that applies to them, and someone installing
from source, similar ...

Another benefit would be the ability, for instance, of there being a plPHP
"project" on pgfoundry, where, when a release is made, the tar file is
copied up to there (by the project maintainer, not by me) ... this would
be good to allow sub-projects like this to be able have their own
discussion forms, bug tracking, etc ... while the main code is still
maintained in the main source tree ...

My primary desire is to avoid having to download several Meg of tar
ball(s) in order to add a module to an existing server ... if that can be
accomplished, then my main objection to adding things to the core CVS are
eliminated ...

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

My primary desire is to avoid having to download several Meg of tar
ball(s) in order to add a module to an existing server ... if that can
be accomplished, then my main objection to adding things to the core CVS
are eliminated ...

I guess I don't see the problem of the PostgreSQL distribution being 11
megs, heck even 50 megs. I know that some places don't have the
bandwidth we do but it only takes me about 90 seconds to download the
distribution.

Sincerely,

Joshua D. Drake

--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

Dave Held wrote:

-----Original Message-----
From: Andrew Dunstan [mailto:andrew@dunslane.net]
Sent: Monday, May 02, 2005 7:05 PM
To: xzilla@users.sourceforge.net
Cc: Dave Held; pgsql-advocacy@postgresql.org;
pgsql-hackers@postgresql.org
Subject: Re: [pgsql-advocacy] [HACKERS] Decision Process WAS:
Increased
company involvement

[...]
I nat happy avout that last point - personally, I value most
highly the views of those who contribute code or similar and
least highly the views of those whose principal contribution
is opinions.

Maybe so, but if you were a new contributor, why would you write
a bunch of code with no assurance that it would go anywhere?

People write code for lots of reasons, only some of which have directly
to do with geting that code into the distributed product.

But I digress :-)

It seems wiser to invest your time familiarizing yourself with
the ins and outs of the codebase and the coding style of patches
by looking at other people's work. It also seems smarter to
lurk and see what kinds of changes are likely to be considered.
I doubt you would think highly of a newcomer that contributed
code that was not in the style of the codebase and was for a
feature not on the TODO list and that didn't get community buy-in
first.

I never suggested otherwise.

But then, how do you get community buy-in if you don't
contribute code, according to you?

The surest path is to do things incrementally. And ask *lots* of
questions. The bigger the development, and the more inexperienced you
are, the more questions you should ask. Just getting the answers to
yuour questions gets you some buyin (unless the consensus answer is
"don't do it"). But the best bet is to build up credibility by doing
small projects to start with.

The postgres processes are nebulous, ill-defined, even. I don't see that
as necessarily a bad thing.

cheers

andrew

Robert Treat wrote:

Is telling the rpm maintainers to go fix their rpm's an option? As has
been hashed out before, the only thing that makes plphp different from
other pl's is that some of the current packagers are taking shortcuts
with the packaging scripts which introduces dependency issues. IMHO what
is included in the postgresql cvs and what is included in the main
tarball for postgresql should not be dictated by outside packagers.

That wasn't my understanding of the previous discussion. Does not php
require pg client support configured in at build time?

cheers

andrew

Robert Treat <xzilla@users.sourceforge.net> writes:

Is telling the rpm maintainers to go fix their rpm's an option? As has
been hashed out before, the only thing that makes plphp different from
other pl's is that some of the current packagers are taking shortcuts
with the packaging scripts which introduces dependency issues. IMHO what
is included in the postgresql cvs and what is included in the main
tarball for postgresql should not be dictated by outside packagers.

"Outside packagers"? What makes you think PG RPMs are built by outside
packagers? The PGDG RPMs are certainly built by us, and Red Hat's PG
RPMs are built by somebody named Tom Lane, and last I heard Oliver
Elphick was handling the Debian packaging. We have more control over
those things than you might think. What we don't have control over is
what the PHP people choose to put in their tarball ... and that means
there's a circularity problem if we try to merge plphp. I think you
are blaming the messengers.

regards, tom lane

On Tuesday 03 May 2005 13:46, Andrew Dunstan wrote:

Robert Treat wrote:

Is telling the rpm maintainers to go fix their rpm's an option? As has
been hashed out before, the only thing that makes plphp different from
other pl's is that some of the current packagers are taking shortcuts
with the packaging scripts which introduces dependency issues. IMHO what
is included in the postgresql cvs and what is included in the main
tarball for postgresql should not be dictated by outside packagers.

That wasn't my understanding of the previous discussion. Does not php
require pg client support configured in at build time?

If your compiling it from source, it works similarly to perl... you only need
pg when compiling pg support into php, but you dont need tthis in for plphp.

The problem stems from things like the php rpm spec, which has a module
dependency on postgresql. This would create a circular dependency if we were
to put a dependency into the pg rpm spec for plphp.

I think the solution to this is to create a seperate rpm spec for php-pgsql
support, which would fall in line with how the php rpm packages are
distributed, but I'm not an expert in rpm specs...

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

On Tue, 3 May 2005, Joshua D. Drake wrote:

My primary desire is to avoid having to download several Meg of tar ball(s)
in order to add a module to an existing server ... if that can be
accomplished, then my main objection to adding things to the core CVS are
eliminated ...

I guess I don't see the problem of the PostgreSQL distribution being 11 megs,
heck even 50 megs. I know that some places don't have the bandwidth we do but
it only takes me about 90 seconds to download the distribution.

Granted, "we in the West" are lucky ... but I know alot of ppl still on
dialup, and I believe there are still alot of places in Europe (or is/was
it just GB?) that pay per byte for their bandwidth ... even myself, at
home, on a cable modem, have at times found downloads to be atrociously
slow due to load n the network ...

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

On Tue, 3 May 2005, Marc G. Fournier wrote:

On Tue, 3 May 2005, Joshua D. Drake wrote:

My primary desire is to avoid having to download several Meg of tar
ball(s) in order to add a module to an existing server ... if that can be
accomplished, then my main objection to adding things to the core CVS are
eliminated ...

I guess I don't see the problem of the PostgreSQL distribution being 11
megs, heck even 50 megs. I know that some places don't have the bandwidth
we do but it only takes me about 90 seconds to download the distribution.

Granted, "we in the West" are lucky ... but I know alot of ppl still on
dialup, and I believe there are still alot of places in Europe (or is/was it
just GB?) that pay per byte for their bandwidth ... even myself, at home, on
a cable modem, have at times found downloads to be atrociously slow due to
load n the network ...

If anyone knows a *good* source for this sort of thing, please send me a
URL, but a quick search on google finds:

"The market share for permanent connections continued to increase in
December and now accounts for 39.4 per cent of all connections. This
compares with a market share of 21.9 per cent a year before."
http://www.i10.org.uk/pooled/articles/BF_NEWSART/view.asp?Q=BF_NEWSART_136457

Which, to me, indicates that ~60.6% of all connections are still dial-up
(does ISDN count as a permanent connection?) ... but, I don't know where
they are getting their #s from, so, as I said, if someone else can point
me to better stats, please do ...

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

Robert Treat wrote:

On Tuesday 03 May 2005 13:46, Andrew Dunstan wrote:

Robert Treat wrote:

Is telling the rpm maintainers to go fix their rpm's an option? As has
been hashed out before, the only thing that makes plphp different from
other pl's is that some of the current packagers are taking shortcuts
with the packaging scripts which introduces dependency issues. IMHO what
is included in the postgresql cvs and what is included in the main
tarball for postgresql should not be dictated by outside packagers.

That wasn't my understanding of the previous discussion. Does not php
require pg client support configured in at build time?

If your compiling it from source, it works similarly to perl... you only need
pg when compiling pg support into php, but you dont need tthis in for plphp.

I suspect you are missing the point completely.

It is in fact not like building perl at all. I just downloaded
php-4.3.11 and got this from configure --help:

--with-pgsql[=DIR] Include PostgreSQL support. DIR is the PostgreSQL
base install directory, defaults to
/usr/local/pgsql.

You will not find any such parameter for building perl.

Now it is true that you don't need this in for plphp. But if you want
php to have pg client support you need pg built first. And no sane
packager is going to build php twice.

I understand (correct me if I'm wrong) that php is moving to get rid of
this compile-time dependency - but it's not gone yet, to the best of my
knowledge.

cheers

andrew

On 4/30/05, Jim C. Nasby <decibel@decibel.org> wrote:

If money's not an issue anymore, can we get a bigger box to host
pgfoundry on then? :)

If you guys are planning on running Gforge, then you better make 'box' plural.

I'm running MamboForge.net, and the poor thing is getting beat into
the cold hard earth every day. We (Mambo) should really have two
servers, at least to dedicate hardware to the database. Most of the
servers in that class are dual Xeons as well - just as an indicator of
what you are getting yourselves into ;-)

Contact me directly if you have any questions about Gforge and
administration or load.

-- Mitch

Mitch Pirtle wrote:

On 4/30/05, Jim C. Nasby <decibel@decibel.org> wrote:

If money's not an issue anymore, can we get a bigger box to host
pgfoundry on then? :)

If you guys are planning on running Gforge, then you better make 'box' plural.

Well we already run it :) For pgFoundry and you are correct it seems to
be a bit of a pig. Our new machines should handle it better though.

Sincerely,

Joshua D. Drake

--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

* Robert Treat (xzilla@users.sourceforge.net) wrote:

If your compiling it from source, it works similarly to perl... you only need
pg when compiling pg support into php, but you dont need tthis in for plphp.

The problem stems from things like the php rpm spec, which has a module
dependency on postgresql. This would create a circular dependency if we were
to put a dependency into the pg rpm spec for plphp.

I think the solution to this is to create a seperate rpm spec for php-pgsql
support, which would fall in line with how the php rpm packages are
distributed, but I'm not an expert in rpm specs...

Just to point it out, Debian handles circular dependencies like these
without too much difficulty. It's really only an issue when first
building the various packages, and then you just build one without all
the support initially, build the other, then rebuild the first with the
support.

So, in general, no, I don't think this should be justification for it
being part of the main source tree and as a Debian maintainer would much
prefer it be seperate and able to be compiled outside of the core
Postgres tree..

Stephen

On Tue, 2005-05-03 at 14:26 -0400, Mitch Pirtle wrote:

If you guys are planning on running Gforge, then you better make 'box' plural.

I'm running MamboForge.net, and the poor thing is getting beat into
the cold hard earth every day. We (Mambo) should really have two
servers, at least to dedicate hardware to the database. Most of the
servers in that class are dual Xeons as well - just as an indicator of
what you are getting yourselves into ;-)

Of course, Mitch is running the second largest GForge site on the planet
(as far as I know).... second only to https://helixcommunity.org/.
Here's a list of them:

http://gforge.org/docman/view.php/1/52/gforge-sites.html

Yours,

Tom Copeland

On Tue, 3 May 2005, Andrew Dunstan wrote:

Robert Treat wrote:

On Tuesday 03 May 2005 13:46, Andrew Dunstan wrote:

Robert Treat wrote:

Is telling the rpm maintainers to go fix their rpm's an option? As has
been hashed out before, the only thing that makes plphp different from
other pl's is that some of the current packagers are taking shortcuts
with the packaging scripts which introduces dependency issues. IMHO what
is included in the postgresql cvs and what is included in the main
tarball for postgresql should not be dictated by outside packagers.

That wasn't my understanding of the previous discussion. Does not php
require pg client support configured in at build time?

If your compiling it from source, it works similarly to perl... you only
need pg when compiling pg support into php, but you dont need tthis in for
plphp.

I suspect you are missing the point completely.

It is in fact not like building perl at all. I just downloaded php-4.3.11 and
got this from configure --help:

--with-pgsql[=DIR] Include PostgreSQL support. DIR is the PostgreSQL
base install directory, defaults to
/usr/local/pgsql.

You will not find any such parameter for building perl.

Now it is true that you don't need this in for plphp. But if you want php to
have pg client support you need pg built first. And no sane packager is going
to build php twice.

Actually, if you look through FreeBSD ports, this is exactly what happens
... when you build /usr/ports/devel/php4, it builds a "vanilla" php, no
modules ... if you want pgsql support, you go into
/usr/ports/databases/php4-pgsql, and build that (which has a dependency on
lang/php4) ...

So, for plphp, a "port" would just have to install /usr/ports/lang/php4 to
build, but would not necessarily build php4-pgsql ...

it is done this way to avoid packagers having to build a monolithich
"contains everything" php4 ...

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

* Tom Lane (tgl@sss.pgh.pa.us) wrote:

Robert Treat <xzilla@users.sourceforge.net> writes:

Is telling the rpm maintainers to go fix their rpm's an option? As has
been hashed out before, the only thing that makes plphp different from
other pl's is that some of the current packagers are taking shortcuts
with the packaging scripts which introduces dependency issues. IMHO what
is included in the postgresql cvs and what is included in the main
tarball for postgresql should not be dictated by outside packagers.

"Outside packagers"? What makes you think PG RPMs are built by outside
packagers? The PGDG RPMs are certainly built by us, and Red Hat's PG
RPMs are built by somebody named Tom Lane, and last I heard Oliver
Elphick was handling the Debian packaging. We have more control over
those things than you might think. What we don't have control over is
what the PHP people choose to put in their tarball ... and that means
there's a circularity problem if we try to merge plphp. I think you
are blaming the messengers.