Re: Call for 7.5 feature completion - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Call for 7.5 feature completion
Date
Msg-id 6BCB9D8A16AC4241919521715F4D8BCE171692@algol.sollentuna.se
Whole thread Raw
In response to Call for 7.5 feature completion  (mike g <mike@thegodshalls.com>)
List pgsql-hackers
> > That is the plan ... unless someone knows a reason why they
> can't be
> > built independently of the core?
>
> How about this one:  Everything we have moved from the core
> to gborg so far has been a miserable failure.  The code is no
> longer maintained, or maintained by three different competing
> groups, the documentation has disappeared, the portability is
> no longer taken care of, and only the bravest souls even dare
> look at the stuff.  I think before you move anything more,
> you need to have a strong, convincing community on the
> receiving side rather than just kicking things out and hoping
> someone will pick it up.  Just because it can be built
> separately doesn't mean everything needs to be.

Another thing is how the end user gets to the files. As an end user,
you'd generally not care which CVS server the code is on. What you *do*
care about is that it's included in the main RPM/DEB or whatever *and*
the main source tarball (if I download "complete server", I certainly
want a complete server. Including for example PLs, which is one of
postgresqls strengths..). Same goes for the docs, of course.

If it's in main CVS you get the benefit of having it included in the
normal "release management". Sure, it adds a burden on the release
management work, but that job has to be done somewhere. And id you just
pull in "whatever version happens to be latest" and put this in the
release version, you are probably in for some nasty surprises.


//Magnus



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Call for 7.5 feature completion
Next
From: Dave Cramer
Date:
Subject: question about information_schema