Re: internal voting

From: "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Iavor Raytchev <iavor(dot)raytchev(at)verysmall(dot)org>, "Bartus(dot) L" <bartus(dot)l(at)bitel(dot)hu>, Boyan Dzambazov <boyan(dot)dzambazov(at)verysmall(dot)org>, Boyan Filipov <boyan(dot)filipov(at)verysmall(dot)org>, Cmaj <cmaj(at)freedomcorpse(dot)info>, Constantin Teodorescu <teo(at)flex(dot)ro>, "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>, "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk>, Stanislav Grozev <stanislav(dot)grozev(at)cees(dot)org>, Thomas Lockhart <lockhart(at)fourpalms(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: internal voting
Date: 2002-05-10 21:42:05
Message-ID: 20020510214205.GD843@rice.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-interfaces

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Trond Eivind =?iso-8859-1?q?Glomsr=F8d?= 2002-05-10 21:44:12 Re: Making the regression tests locale-proof
Previous Message Iavor Raytchev 2002-05-10 21:40:28 pgaccess - the discussion is over

Browse pgsql-interfaces by date

  From Date Subject
Next Message Thomas Lockhart 2002-05-10 22:06:47 Re: internal voting
Previous Message Iavor Raytchev 2002-05-10 21:40:28 pgaccess - the discussion is over