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
