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

On Thu, May 09, 2002 at 10:24:00PM +0200, Iavor Raytchev wrote:

<nice summary of how we got here>

PROPOSAL

What pgaccess needs is some fresh air - it needs a small and fresh team. It
needs own web site, own cvs, own mailing list. So that the people who love
it, write for it and really need it can be easy to identify and to talk to.
This will not break its relationship to PostgreSQL in any way (see 3] above)

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. 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. 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.

At the end - I am not experienced how decisions are taken in an open source
community - I have no idea what is next.

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.

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.

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.

Ross

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

Hi everybody,

I think, that our "job" is to help this project to grow up to fit the
needs of the people that are using it. In the last months I didn't
notice any activity around it. And there are real expectations that are
still unsatisfied.

This project really needs the fresh air. I think, to have the
pgaccess.org is something good, and we shold make this whole thing work.

So let's do it!

Let's take the last stable release, let's apply the patches, and let's
put it on the pgaccess.org, where everybody can reach it easily. If we
find some other patches we can easily apply them too.
The source is very "readable", not too complicated, even as a beginner
in tcl I was able to make useful changes. Congratulations to Teo, he
did a very good job.

To have an enthusiastic group of developers around the pgaccess is good
for the postgres teem too.

Once again: LET'S DO IT!

Levi.

P.S: In the near future I'm planning to make the hungarian translation
too.

On Thu, 9 May 2002, Iavor Raytchev wrote:

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?

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.

From a PgSQL Project standpoint, pgaccess has always been included as a
way of increasing the overall distribution of the package as a valid GUI
interface ... all that has ever happened in the past is that when a new
release came out from Teo, Bruce has generally downloaded it and replaced
what we had in CVS ... there were no patches involved ... I don't see why
that has to change, does it?

If the pgaccess.org folk would like, I can provide them with a means of
being able to easily upload a new copy of each release to
ftp.postgresql.org, so that it can make use of the extensive distribution
system wthat has been developeed over the years ... just let me know ...

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

From a PgSQL Project standpoint, pgaccess has always been included as a
way of increasing the overall distribution of the package as a valid GUI
interface ... all that has ever happened in the past is that when a new
release came out from Teo, Bruce has generally downloaded it and replaced
what we had in CVS ... there were no patches involved ... I don't see why
that has to change, does it?

Ideally I think there should be only one master CVS copy of pgaccess ---
either that should be the one in the postgresql.org tree, or we should
remove pgaccess from postgresql.org and let it become a standalone
project with its own CVS someplace else. I know that right now, there
are some changes in the postgresql.org tree that are not in Teo's tree,
because I made some 7.2 fixes there last summer (having forgotten that
our sources were not the master copy). This is not good, but it'll
keep happening if there are multiple CVS trees.

Which of those approaches to take is pretty much up to the new
maintainers of pgaccess --- if you guys would rather be a separate
project, fine, or we can work with you if you want postgresql.org
to be the CVS repository. Personally I'd vote for the latter.
The JDBC folks have been working pretty successfully as a sub-project
within the postgresql.org tree, so I think you could do the same.
But you might get more "name recognition" as a separate project.

If the pgaccess.org folk would like, I can provide them with a means of
being able to easily upload a new copy of each release to
ftp.postgresql.org, so that it can make use of the extensive distribution
system wthat has been developeed over the years ... just let me know ...

Right, if there's a separate CVS we can still arrange to be an FTP
distribution channel.

regards, tom lane

On Thu, 9 May 2002, Tom Lane wrote:

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

From a PgSQL Project standpoint, pgaccess has always been included as a
way of increasing the overall distribution of the package as a valid GUI
interface ... all that has ever happened in the past is that when a new
release came out from Teo, Bruce has generally downloaded it and replaced
what we had in CVS ... there were no patches involved ... I don't see why
that has to change, does it?

Ideally I think there should be only one master CVS copy of pgaccess ---
either that should be the one in the postgresql.org tree, or we should
remove pgaccess from postgresql.org and let it become a standalone
project with its own CVS someplace else. I know that right now, there
are some changes in the postgresql.org tree that are not in Teo's tree,
because I made some 7.2 fixes there last summer (having forgotten that
our sources were not the master copy). This is not good, but it'll
keep happening if there are multiple CVS trees.

Which of those approaches to take is pretty much up to the new
maintainers of pgaccess --- if you guys would rather be a separate
project, fine, or we can work with you if you want postgresql.org
to be the CVS repository. Personally I'd vote for the latter.
The JDBC folks have been working pretty successfully as a sub-project
within the postgresql.org tree, so I think you could do the same.
But you might get more "name recognition" as a separate project.

I'm not part of this pgaccess group but having the repository at postgresql.org
makes sense to me as refreshing a local tree to capture changes to postgres is
also going to bring in any commited changes to pgaccess. That's easiest for
keeping everything in step, since breakages are going to be apparent straight
away. If there's a separate repository then it's easy to see someone keeping
upto date with one but not the other and ending up in a mess.

On the other hand, I also quite like the idea of it being maintained as a
separate entity with some sort of push to the main repository. I was also
trying to make a case for this based on the ease of enhancing and releasing
functionality for those not on the bleeding edge but I'm not so sure now since
that requires all fixes to keep in step with the backend to backwards
compatible.

[snip]

--
Nigel J. Andrews
Director

---
Logictree Systems Limited
Computer Consultants

What about http://sourceforge.net/projects/pgaccess/? It looks
inactive but somebody did set it up on 2002-04-25. I think I
found it from Teo's website.

MikE

Tom Lane wrote:

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

From a PgSQL Project standpoint, pgaccess has always been included as a
way of increasing the overall distribution of the package as a valid GUI
interface ... all that has ever happened in the past is that when a new
release came out from Teo, Bruce has generally downloaded it and replaced
what we had in CVS ... there were no patches involved ... I don't see why
that has to change, does it?

Ideally I think there should be only one master CVS copy of pgaccess ---
either that should be the one in the postgresql.org tree, or we should
remove pgaccess from postgresql.org and let it become a standalone
project with its own CVS someplace else. I know that right now, there
are some changes in the postgresql.org tree that are not in Teo's tree,
because I made some 7.2 fixes there last summer (having forgotten that

^^^^^^^^^^^^^^^^^^^^^

our sources were not the master copy). This is not good, but it'll

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

keep happening if there are multiple CVS trees.

[ Just catching up.]

Actually, the PostgreSQL CVS tree is the master pgacces source since Teo
stopped working on it. I used to pass patches back to him but at one
point he told me that we should maintian the master copy.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026