Re: internal voting

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