Re: www.pgaccess.org - the official story (the way I saw it)

From: "Iavor Raytchev" <iavor(dot)raytchev(at)verysmall(dot)org>
To: "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>
Cc: "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>, "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk>, "Thomas Lockhart" <lockhart(at)fourpalms(dot)org>, "Constantin Teodorescu" <teo(at)flex(dot)ro>, "Boyan Dzambazov" <boyan(dot)dzambazov(at)verysmall(dot)org>, "Bartus(dot) L" <bartus(dot)l(at)bitel(dot)hu>, "Stanislav Grozev" <stanislav(dot)grozev(at)cees(dot)org>, "Boyan Filipov" <boyan(dot)filipov(at)verysmall(dot)org>, "C(dot) Maj" <cmaj(at)freedomcorpse(dot)info>
Subject: Re: www.pgaccess.org - the official story (the way I saw it)
Date: 2002-05-09 21:08:17
Message-ID: HKEIIDPFPDBMOMDLIEEGCECFCGAA.iavor.raytchev@verysmall.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thanks Ross,

This sounds like a resolution.

> I'd suggest keeping a copy of pgaccess in the main tree, as well, and
> pushing versions from the development CVS over on a regular basis.

I am not a cvs expert. We will check this with Stanislav - our system
administrator, when he is back from holiday on Monday. I am sure there
should be an automated way of keeping things fresh.

Who is the contact person for the PostgreSQL cvs?

> There
> are basically two types of development that will need to happen: adapting
> pgaccess to changes in PostgreSQL, and developing new features, on top
> of the stable release of PostgreSQL.

Right.

It will be nice if we can have assigned liaison officers on the PostgreSQL
side who can father the relationship with the pgaccess.org team. Regular
sessions when a release of PostgreSQL is about to happen also might improve
the work a lot.

> I suggest having two branches at
> cvs.pgaccess.org: one that tracks HEAD of pgsql, one that uses the latest
> stable release. As features stablize on the second branch, we push them
> over to the pgsql branch, then into the pgsql tree, itself. Note that
> we might be able to write some pgaccess regression tests: at minimum,
> some sanity tests on the schema we store in the database. At postgresql
> release time, we'd make sure to get the latest, freshest code into the
> main tree, and distributions.

This sounds beautiful. There is more meaning in it than words. I need to
sleep on it to get it, and we need some time to set this process up. But I
am sure we should follow this if we want to get anywhere.

> Like this! Out in the open, on the mailing lists. This message of
> yours was
> exactly the right thing to post: you contacted the original
> maintainer, got
> the 'mantle' passed over to the new group, and continue on.

Well, let's hope people will like it. We started doing it for our own needs.
Now suddenly it became the centre of the Universe :)

> It might be good to get a mailing list at the main site, rather than
> running our own: that way, people will find it, and Bruce or someone
> has an easy place to push patches he receives for our approval.

Yes, this will happen next week. We just launched this server and we need
few more days to organize.

> > May be one can write a summary what are the bad sides of the
> above proposal.
> > And if there are no such really - we should just proceed and
> have this nice
> > tool alive and running.
>
> Only bad thing would be to let the code in the main postgresql tree rot:
> either we keep it fresh, or we ask to have it pulled.

Well... as I said to Teo, Chris and Bartus when we started pgaccess.org - we
need it and we start it. If we fall out of business and can not provide the
server anymore - somebody else should take over. And they agreed to take the
risk. Until we are alive and breathing - we will be doing it. And until we
are doing it - it will be fresh and blooming.

Thanks again,

Iavor

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message mlw 2002-05-09 21:09:56 Re: Issues tangential to win32 support
Previous Message Jan Wieck 2002-05-09 20:49:11 Re: the parsing of parameters