internal voting

On Fri, 10 May 2002 10:58:28 +0200
"Iavor Raytchev" <iavor.raytchev@verysmall.org> wrote:

Hello everybody,

After Marc Fournier commented, it is time for pgaccess.org to make a
decision.

It is clear the project needs the following tools.

- web site
- mailing list(s)
- cvs
- bug tracking system

It is clear, that there is a small new group with fresh desire to
contribute in a dedicated way.

It is clear, that pgaccess has only one meaning and this is PostgreSQL.

It is clear, that the PostgreSQL core team is very supportive.

It is clear, that pgaccess.org efforts can not result in anything good
without a close collaboration with the PostgreSQL core team.

Now, when we heard many different opinions, the question is - what is
the best decision of organization.

I would make the following summary, please, send your comments -

SUMMARY

1] In terms of infrastructure, a separate web site, mailing list(s) and
bug tracking system will increase the flexibility of the pgaccess team
and will not create additional (and not very useful) burden for the
PostgreSQL core team. The pgaccess is a tool - it is not an integral
part of PostgreSQL and does not need day-to-day sharing. In the
beginning it will be developed rather for the stable, than for the
future versions of PostgreSQL.

2] It is clear that there must be one master copy of the CVS. The
possibilities are two - this copy is kept with PostgreSQL or this copy
is kept with pgaccess.org

If the PostgreSQL core team can provide a CVS repository with similar
flexibility to that it would have being based on the pgaccess.org server
- I would vote for a PostgreSQL hosted CVS. This will be the naval cord
between the two projects.

3] Still - the only thing that is not clear to me is - who is going to
collect all patches and make one whole form them. As long as each of us
works on a different thing - this should not be a big problem, but still
- needs to be one person.

This looks all good to me, except I have one question: How will pgaccess
be distributed? Personally, I like the idea that PG comes with pgaccess in
the distribution, so I would hate to see that go away. Even though there
are people that don't use pgaccess, it is always nice to have a default
tool that comes with PG (yes, I know there is psql).

--brett

p.s. I am willing to help out as well...

Iavor Raytchev writes:

3] Still - the only thing that is not clear to me is - who is going to
collect all patches and make one whole form them. As long as each of us
works on a different thing - this should not be a big problem, but still -
needs to be one person.

As far as I'm concerned, there is no need to change anything. If someone
has patches for pgaccess, send them to -patches and they will be applied.
When a new release of PostgreSQL happens, a new pgaccess will be
distributed. Simple enough.

If and when patches for pgaccess appear in significant numbers and for
some reason, which I cannot imagine, this procedure doesn't end up being
practical, we can consider the alternatives. But before you spend a lot
of time building a new infrastructure, let's see some code.

--
Peter Eisentraut peter_e@gmx.net

If and when patches for pgaccess appear in significant numbers and for
some reason, which I cannot imagine, this procedure doesn't end up being
practical, we can consider the alternatives. But before you spend a lot
of time building a new infrastructure, let's see some code.

--
Peter Eisentraut peter_e@gmx.net

We are working on it, because we have some code.

Don't you believe us, or do you think we have a lot of free time to waste?

We - Chris, Bartus, Boyan and myself, have enough patches we want to merge.
And we do not feel like asking for permisson to do it. We sent them to Teo
and we were asked by Teo to meet and see what we can do with our patches.
And we were nice enough to tell the world about this.

I do not feel neither like 'asking for permisson', nor like 'proving'
anything. If somebody wants to help - is welcome.

I think the discussion is over.

We have some work to do.

Iavor

On Fri, May 10, 2002 at 11:24:40PM +0200, Peter Eisentraut wrote:

Iavor Raytchev writes:

3] Still - the only thing that is not clear to me is - who is going to
collect all patches and make one whole form them. As long as each of us
works on a different thing - this should not be a big problem, but still -
needs to be one person.

As far as I'm concerned, there is no need to change anything. If someone
has patches for pgaccess, send them to -patches and they will be applied.
When a new release of PostgreSQL happens, a new pgaccess will be
distributed. Simple enough.

If and when patches for pgaccess appear in significant numbers and for
some reason, which I cannot imagine, this procedure doesn't end up being
practical, we can consider the alternatives. But before you spend a lot
of time building a new infrastructure, let's see some code.

All very practical, execpt for one point: the people being pulled togther
for this _have_ code, with nowhere to put it: they've been developing
new features for pgaccess, on top of the stable pgsql. Tracking CVS
tip means that the current version of pgaccess there is either broken
by underlying pgsql changes (I think that is currently true with Tom's
schema work) or does not work with the current stable version og pgsql.

While it would be nice to have one pgaccess that can work with any pgsql
backend, that's not currently the case. One solution would be to work
on the release branch, but that's discouraged - bug fixes only.

Ross

...

While it would be nice to have one pgaccess that can work with any pgsql
backend, that's not currently the case. One solution would be to work
on the release branch, but that's discouraged - bug fixes only.

Actually, CVS can support this just fine (I'll mention how below) but
afaict the discussion is moot because Iavor has declared that his group
prefers to take another path for now.

- Thomas

The solution could be to make a branch off of the stable branch to
support the pgaccess work. When folks are ready to merge down and
develop for 7.3, then they can do that using the "-j" option, jumping
straight from their development branch down to the main trunk (hence
never corrupting the stable branch), and then develop from there.

Actually, CVS can support this just fine (I'll mention how below) but
afaict the discussion is moot because Iavor has declared that his group
prefers to take another path for now.

- Thomas

It is not 'my' group! I just happened to ask somebody in my company to patch
something and then I send the code to Teo. And Teo asked Chris, Bartus and
myself to bring our patches together. And I though of making this public.

The discussion, however, went far beyond my intention.

If somebody feels like managing this - I am off. I do not intend to moderate
the future of an open source project in such a heavy climate. Especialy of a
project I am not the author, not even a contributor - I am a pure manager.

If nobody feels like managing this - let's give it a little bit of life and
move it a bit forwards - and then talk again.

Nothing wrong can happen the next two weeks.

Iavor

...

If nobody feels like managing this - let's give it a little bit of life and
move it a bit forwards - and then talk again.

Iavor, I meant to be helpful; I was trying to put a name on The New
Group of Enthusiastic Developers Who Are Interested In Advancing
Pgaccess and shortened it to "Iavor's group". :)

Nothing wrong can happen the next two weeks.

Certainly true. As The Developers Who Are Always Interested In Advancing
PostgreSQL And Really Like Pgaccess, we have just been trying to be
helpful and to make TNGoEDWAIIAP feel welcome to take advantage of any
existing or new resources in postgresql.org which they might want. So,
please know that TDWAAIIAPARLP are happy to support anything that
TNGoEDWAIIAP might want to do.

Regards.

- Thomas

Thomas :)))

In Europe it is 1:40 a.m.

Wish you a good night :)

And thanks,

Iavor

--
TNGoEDWAIIAP

-----Original Message-----
From: lockhart@fourpalms.org [mailto:lockhart@fourpalms.org]
Sent: Saturday, May 11, 2002 1:32 AM
To: Iavor Raytchev
Cc: pgsql-hackers; Tom Lane; Stanislav Grozev; Ross J. Reedstrom; Nigel
J. Andrews; Marc G. Fournier; Constantin Teodorescu; Cmaj; Boyan
Filipov; Boyan Dzambazov; Bartus. L; Brett Schwarz
Subject: Re: [HACKERS] internal voting

...

If nobody feels like managing this - let's give it a little bit of life

and

move it a bit forwards - and then talk again.

Iavor, I meant to be helpful; I was trying to put a name on The New
Group of Enthusiastic Developers Who Are Interested In Advancing
Pgaccess and shortened it to "Iavor's group". :)

Nothing wrong can happen the next two weeks.

Certainly true. As The Developers Who Are Always Interested In Advancing
PostgreSQL And Really Like Pgaccess, we have just been trying to be
helpful and to make TNGoEDWAIIAP feel welcome to take advantage of any
existing or new resources in postgresql.org which they might want. So,
please know that TDWAAIIAPARLP are happy to support anything that
TNGoEDWAIIAP might want to do.

Regards.

- Thomas

Ross J. Reedstrom writes:

All very practical, execpt for one point: the people being pulled togther
for this _have_ code, with nowhere to put it: they've been developing
new features for pgaccess, on top of the stable pgsql. Tracking CVS
tip means that the current version of pgaccess there is either broken
by underlying pgsql changes (I think that is currently true with Tom's
schema work) or does not work with the current stable version og pgsql.

We went through a very similar situation with the JDBC driver a release
ago. A number of people had developed fixes or features for the driver
and no one was collecting them. We've got those people working on the 7.2
branch and everything worked out well. Yes, this meant that the features
and fixes were not immediately available in the 7.1 branch. But the
alternative of forking pgaccess now is that the available fixes and
features will not be available in the 7.3 branch for quite a while.

--
Peter Eisentraut peter_e@gmx.net

On 2002.05.11 14:15 Peter Eisentraut wrote:

Ross J. Reedstrom writes:

All very practical, execpt for one point: the people being pulled

togther

for this _have_ code, with nowhere to put it: they've been

developing

new features for pgaccess, on top of the stable pgsql. Tracking CVS
tip means that the current version of pgaccess there is either

broken

by underlying pgsql changes (I think that is currently true with

Tom's

schema work) or does not work with the current stable version og

pgsql.

We went through a very similar situation with the JDBC driver a
release
ago. A number of people had developed fixes or features for the
driver
and no one was collecting them. We've got those people working on the
7.2
branch and everything worked out well. Yes, this meant that the
features
and fixes were not immediately available in the 7.1 branch. But the
alternative of forking pgaccess now is that the available fixes and
features will not be available in the 7.3 branch for quite a while.

But we have fixes and patches for this (7.2) version, why we sould wait
for the next version. I think, there is no connection (should not be)
between the versions of the pgaccess and the versions of the pgsql.
Pgaccess is a visual tool for pgsql, that can be developed freely
without having anything to do with the pgsql developement.
So I cannot understand why the majority of the oppinions says that
pgaccess should stay in the shadow of the pgsql.
Breaking this tight connection we can help pgaccess to develop as fast
as it can, and we let free space for other projects to appear. For me
the first thing is to make my daily job as good and fast as I can. And
this is much easier with using the best tool for the particular
problem. This is why I started to make patches to this project.
Sorry but I can't wait for the next pgsql release to have this patches
included in the package.

Peter Eisentraut <peter_e@gmx.net> writes:

We went through a very similar situation with the JDBC driver a release
ago. A number of people had developed fixes or features for the driver
and no one was collecting them. We've got those people working on the 7.2
branch and everything worked out well. Yes, this meant that the features
and fixes were not immediately available in the 7.1 branch.

Au contraire --- what the JDBC folk did (and still are doing) was to
make "unofficial" releases consisting of snapshots pulled from their
chunk of the CVS tree. There were people making use of the "7.2 branch"
of JDBC long before the 7.2 server went beta, let alone final.

Now this worked only because the JDBC driver makes a point of working
with older server versions as well as current, so it was possible to
use the updated driver with 7.1 and even older servers. I don't know
whether pgaccess does or should have a similar policy, but if it does
then the same approach should work well for it.

The alternative of maintaining a separate CVS tree and a separate
release schedule would really force exactly that policy on pgaccess
anyway --- if your releases aren't tied to the server's then you can
hardly expect to be sure which server version people will try to use
your code with.

On the other hand, if the pgaccess developers would rather maintain
separate pgaccess versions for each server version, I see no reason
why they couldn't do that in the context of our CVS. They could work
in the REL7_2 branch for now (and make releases from it) then merge
forward to HEAD when they want to start thinking about 7.3 issues.
Or double-patch if they want to work on both versions concurrently.

regards, tom lane

On Sat, 11 May 2002, Tom Lane wrote:

Au contraire --- what the JDBC folk did (and still are doing) was to
make "unofficial" releases consisting of snapshots pulled from their
chunk of the CVS tree. There were people making use of the "7.2 branch"
of JDBC long before the 7.2 server went beta, let alone final.

Now this worked only because the JDBC driver makes a point of working
with older server versions as well as current, so it was possible to
use the updated driver with 7.1 and even older servers. I don't know
whether pgaccess does or should have a similar policy, but if it does
then the same approach should work well for it.

Ah, I'm just composing an email on this subject destined for the -interfaces
list.

The alternative of maintaining a separate CVS tree and a separate
release schedule would really force exactly that policy on pgaccess
anyway --- if your releases aren't tied to the server's then you can
hardly expect to be sure which server version people will try to use
your code with.

On the other hand, if the pgaccess developers would rather maintain
separate pgaccess versions for each server version, I see no reason
why they couldn't do that in the context of our CVS. They could work
in the REL7_2 branch for now (and make releases from it) then merge
forward to HEAD when they want to start thinking about 7.3 issues.
Or double-patch if they want to work on both versions concurrently.

Really, I'd like interested parties to have look at waht I'm posting to
-interfaces so they can shoot down my ideas on this.

--
Nigel J. Andrews
Director

---
Logictree Systems Limited
Computer Consultants

[Note, I've changed the headers so everyone on the original distribution list
is getting a copy via Bcc, including -hackers. It was the simplest way I could
think of making certain the discussion moved to -interfaces as Marc requested.]

On Sat, 11 May 2002, Bartus Levente wrote:

... I think, there is no connection (should not be)
between the versions of the pgaccess and the versions of the pgsql.
Pgaccess is a visual tool for pgsql, that can be developed freely
without having anything to do with the pgsql developement.

Yes.

So I cannot understand why the majority of the oppinions says that
pgaccess should stay in the shadow of the pgsql.

Who said shadow? FWIW, I'd never have bothered about pgaccess, that's even I'd
even known about it, if it hadn't come in the main postgres tree.

Breaking this tight connection we can help pgaccess to develop as fast
as it can, and we let free space for other projects to appear. For me
the first thing is to make my daily job as good and fast as I can. And
this is much easier with using the best tool for the particular
problem. This is why I started to make patches to this project.
Sorry but I can't wait for the next pgsql release to have this patches
included in the package.

Uhoh, now we have a problem, unless your version is going to form the
initial repository or there's little or no impact across the preexisting code.

--
Nigel J. Andrews
Director

---
Logictree Systems Limited
Computer Consultants

On 2002.05.11 20:27 Nigel J. Andrews wrote:

[Note, I've changed the headers so everyone on the original
distribution list
is getting a copy via Bcc, including -hackers. It was the simplest way
I could
think of making certain the discussion moved to -interfaces as Marc
requested.]

On Sat, 11 May 2002, Bartus Levente wrote:

... I think, there is no connection (should not be)
between the versions of the pgaccess and the versions of the pgsql.
Pgaccess is a visual tool for pgsql, that can be developed freely
without having anything to do with the pgsql developement.

Yes.

So I cannot understand why the majority of the oppinions says that
pgaccess should stay in the shadow of the pgsql.

Who said shadow? FWIW, I'd never have bothered about pgaccess, that's
even I'd
even known about it, if it hadn't come in the main postgres tree.

Breaking this tight connection we can help pgaccess to develop as

fast

as it can, and we let free space for other projects to appear. For

me

the first thing is to make my daily job as good and fast as I can.

And

this is much easier with using the best tool for the particular
problem. This is why I started to make patches to this project.
Sorry but I can't wait for the next pgsql release to have this

patches

included in the package.

Uhoh, now we have a problem, unless your version is going to form the
initial repository or there's little or no impact across the
preexisting code.

Sure, there is a problem, that's why the whole discussion started. A
software project stalled for at least a year. Why? There is no need for
it? I can hardly beleive.

Sorry, but I cannot understand your last sentence. Could you explain to
me, please?

I don't want to hurt anybody's feelings, I just want to help this
software to be better, nothing more.

--
Nigel J. Andrews
Director

---
Logictree Systems Limited
Computer Consultants

Best regards,
Levi.

On Sat, 11 May 2002, Bartus Levente wrote:

On 2002.05.11 20:27 Nigel J. Andrews wrote:

On Sat, 11 May 2002, Bartus Levente wrote:

[snip]
problem. This is why I started to make patches to this project.
Sorry but I can't wait for the next pgsql release to have this
patches included in the package.

Uhoh, now we have a problem, unless your version is going to form the
initial repository or there's little or no impact across the
preexisting code.

[snip]

Sorry, but I cannot understand your last sentence. Could you explain to
me, please?

All I mean is that if your patches are making major changes to the majority of
the files making up pgaccess and that the new CVS repository is going to be
initialised from a version that does not have your patches _and_ that this
initial version has been patched by others then there is possibly going to be a
lot of work to bring your patches into CVS. On the hand I suppose this could
just be viewed as the normal problem of merging patches so I'm inclined to not
worry. However, if people are working on pgaccess at the moment then
it is a good idea that their work is applied to pgaccess in the postgres tree
so everyone else can get their hands on it while we wait for the new CVS.

I am assuming here that there is a new CVS repository coming along for
pgaccess, that it will be initialised with the code from the postgres tree [and
that pgaccess in the postgres tree will be synchronised frequently].

I don't want to hurt anybody's feelings, I just want to help this
software to be better, nothing more.

Mine aren't hurt :)

--
Nigel J. Andrews
Director

---
Logictree Systems Limited
Computer Consultants

On 2002.05.11 23:57 Nigel J. Andrews wrote:

On Sat, 11 May 2002, Bartus Levente wrote:

On 2002.05.11 20:27 Nigel J. Andrews wrote:

On Sat, 11 May 2002, Bartus Levente wrote:

[snip]
problem. This is why I started to make patches to this project.
Sorry but I can't wait for the next pgsql release to have this
patches included in the package.

Uhoh, now we have a problem, unless your version is going to form

the

initial repository or there's little or no impact across the
preexisting code.

[snip]

Sorry, but I cannot understand your last sentence. Could you explain

to

me, please?

All I mean is that if your patches are making major changes to the
majority of
the files making up pgaccess and that the new CVS repository is going
to be
initialised from a version that does not have your patches _and_ that
this
initial version has been patched by others then there is possibly
going to be a
lot of work to bring your patches into CVS. On the hand I suppose this
could
just be viewed as the normal problem of merging patches so I'm
inclined to not
worry. However, if people are working on pgaccess at the moment then
it is a good idea that their work is applied to pgaccess in the
postgres tree
so everyone else can get their hands on it while we wait for the new
CVS.

We would like to merge our patches into the last release of the
pgaccess (apperently this is now in the postgres tree), and make this
for the future patches too.
So we set up pgaccess.org, with it's own cvs, mailing lists and
homepage. When Iavor searched for the last release almost a war started.

I am assuming here that there is a new CVS repository coming along for
pgaccess, that it will be initialised with the code from the postgres
tree [and
that pgaccess in the postgres tree will be synchronised frequently].

We would like to syncronise the postgres tree, and to give people a
place where they can find the software, tha latest release, can drop
wishes, and browse the to-do list easier. Is there any to-do list in
the postgres package regarding the pgaccess?

I don't want to hurt anybody's feelings, I just want to help this
software to be better, nothing more.

Mine aren't hurt :)

--
Nigel J. Andrews
Director

---
Logictree Systems Limited
Computer Consultants

Best regards,
Levi.

Iavor Raytchev wrote:

If and when patches for pgaccess appear in significant numbers and for
some reason, which I cannot imagine, this procedure doesn't end up being
practical, we can consider the alternatives. But before you spend a lot
of time building a new infrastructure, let's see some code.

--
Peter Eisentraut peter_e@gmx.net

We are working on it, because we have some code.

Don't you believe us, or do you think we have a lot of free time to waste?

We - Chris, Bartus, Boyan and myself, have enough patches we want to merge.
And we do not feel like asking for permisson to do it. We sent them to Teo
and we were asked by Teo to meet and see what we can do with our patches.
And we were nice enough to tell the world about this.

I do not feel neither like 'asking for permisson', nor like 'proving'
anything. If somebody wants to help - is welcome.

I find that this group is frustrating to work with. They seem very intolerant
of the plurality.

I did a configuration patch several months ago. I liked it, as did some others.
It did not affect any existing behavior, but added the ability to store
configuration information in a different location than the data, and share
files between multiple PostgreSQL instances.

Rather than evaluate the patch, and say it needs these changes, or simply
applying it, you know, working with the contributor's to make a better project,
they ranted and raved how they didn't like it, how they wanted something
better, etc. No good technical reasons were given, mind you, just "I don't like
this."

So, I did the work, for what? Nothing. It is pointless for me to make the
changes for each release. Fortunately it wasn't too much work. So, my
experience tells me that unless the work you do is something they want, you are
wasting your time. If you try to get some feedback from them about an approach
you wish to take, so you don't waste your time, they flame you and tell you to
put up or shut up.

If you intend to undertake a major work on PostgreSQL, it had better be for
something other than contribution back to the group, otherwise, there is a good
possibility that you are going to waste your time.

I do not get paid to work on PostgreSQL, the time I spend on it is either my
own or for a project I am working on. I am finding it very unsatisfying.

On Mon, 13 May 2002, mlw wrote:

Iavor Raytchev wrote:

If and when patches for pgaccess appear in significant numbers and for
some reason, which I cannot imagine, this procedure doesn't end up being
practical, we can consider the alternatives. But before you spend a lot
of time building a new infrastructure, let's see some code.

--
Peter Eisentraut peter_e@gmx.net

We are working on it, because we have some code.

Don't you believe us, or do you think we have a lot of free time to waste?

We - Chris, Bartus, Boyan and myself, have enough patches we want to merge.
And we do not feel like asking for permisson to do it. We sent them to Teo
and we were asked by Teo to meet and see what we can do with our patches.
And we were nice enough to tell the world about this.

I do not feel neither like 'asking for permisson', nor like 'proving'
anything. If somebody wants to help - is welcome.

I find that this group is frustrating to work with. They seem very intolerant
of the plurality.

I did a configuration patch several months ago. I liked it, as did some others.
It did not affect any existing behavior, but added the ability to store
configuration information in a different location than the data, and share
files between multiple PostgreSQL instances.

Rather than evaluate the patch, and say it needs these changes, or simply
applying it, you know, working with the contributor's to make a better project,
they ranted and raved how they didn't like it, how they wanted something
better, etc. No good technical reasons were given, mind you, just "I don't like
this."

So, I did the work, for what? Nothing. It is pointless for me to make the
changes for each release. Fortunately it wasn't too much work. So, my
experience tells me that unless the work you do is something they want, you are
wasting your time. If you try to get some feedback from them about an approach
you wish to take, so you don't waste your time, they flame you and tell you to
put up or shut up.

If you intend to undertake a major work on PostgreSQL, it had better be for
something other than contribution back to the group, otherwise, there is a good
possibility that you are going to waste your time.

I do not get paid to work on PostgreSQL, the time I spend on it is either my
own or for a project I am working on. I am finding it very unsatisfying.

This is the unfortunate impression I'm getting from some people on the
HACKERS list, which is why discussion has moved temporarily to
INTERFACES until pgaccess.org has its own mailing list. Plus that and
the fact that pgaccess is an interface to postgresql. Also, INTERFACES
seems to be a lot more newbie questions but these people are trying to
learn so it is a more welcoming environment.

What is strange is that you weren't even talking about a fork, which
seems to be the central philosophical issue with pgaccess at the moment.
All I can say to reassure people is that it is still _PG_access, not
_access_ *ick*.

--Chris

--

cmaj_at_freedomcorpse_dot_info
fingerprint 5EB8 2035 F07B 3B09 5A31 7C09 196F 4126 C005 1F6A

[trimmed cc list, but left on HACKERS due to the nature of the subject (which
was changed]
On Monday 13 May 2002 10:56 am, mlw wrote:

Iavor Raytchev wrote:

Peter Eisentraut wrote:

let's see some code.

I do not feel neither like 'asking for permisson', nor like 'proving'
anything. If somebody wants to help - is welcome.

I find that this group is frustrating to work with. They seem very
intolerant of the plurality.

I did a configuration patch several months ago. I liked it, as did some
others. It did not affect any existing behavior, but added the ability to
store configuration information in a different location than the data, and
share files between multiple PostgreSQL instances.

While I personally felt that your patch was useful, there were other concerns.

Rather than evaluate the patch, and say it needs these changes, or simply
applying it, you know, working with the contributor's to make a better
project, they ranted and raved how they didn't like it, how they wanted
something better, etc. No good technical reasons were given, mind you, just
"I don't like this."

I think you might want to reread that thread. There _were_ in fact technical
aspects of the situation -- primarily due to the _plurality_ of the
development process around here. It isn't 'plural' to have someone announce
that they have a patch, and then it gets applied without the discussion of
the established developers. No -- changes to this codebase are done by a
plurality -- meaning the entire pgsql-hackers group. (Well, at least that's
how it's supposed to be -- it doesn't always work that way.....).

Your patch was discussed -- the resolution seemed to me to be in favor of
including that functionality in 7.3. To which I was very happy.

This isn't the Linux kernel with a benevolent dictator who can unilaterally
apply patches -- this is an oligarchy with the six core developers, together
with the rest of us, making those decisions as a group. The discussions
aren't flames -- at least I didn't take any of those discussions to be
flames. While there are a few opinionated ones here (myself included), we do
tend to take things on technical merit. Had you patch merited inclusion
without discussion -- well, that wouldn't have happened, regardless of its
merits -- we were in beta, IIRC. IIRI, then I apologize. In beta new
features are frowned upon -- and your patch introduced a substantial new
feature, one that needed careful thought before implemention.

While your patch works for you, as written it didn't necessarily work for
everyone. BTW, it would have worked great for me and my purposes, but
PostgreSQL isn't a vehicle for my personal purposes.

The discussion I remember was a little antsy primarily due to the fact that we
were in beta. Then was not the time; now is. Reintroduce the topic now, and
let's see what happens.

I do not get paid to work on PostgreSQL, the time I spend on it is either
my own or for a project I am working on. I am finding it very unsatisfying.

I do not currently get paid for working on it either. Do I find it
satisfying? Most of the time I do. But if you don't find it satisfying,
well, there could be more than one reason.

But the biggest problem I see was the inappropriate timing of the patch.
Again, _NOW_ would be a good time to reintroduce the topic, as we're not in
beta, and all of the developers are much more likely to be open to these
ideas. But go back to the previous thread in the archives and see where we
left off first, so that everybody starts on the same page of music.

But understand that those who don't need the functionality are likely not not
be thrilled by changes to a currently stable codebase. Although this config
file stuff is small potatoes compared to the Win32 stuff as recently
discussed. And for that, please understand that most of the developers here
consider Win32 an inferior server platform. In fact, Win32 _is_ an inferior
server platform, at least in my opinion. But, if you want to do the work,
and it doesn't break my non-Win32 server build, by all means go for it.

With that said, I hope you'll consider sticking it out and seeing it through
at least two major cycles.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11