On Fri, 19 Sep 2003, Tom Lane wrote:
> I think we could definitely adopt a policy of "on-disk changes not
> oftener than every X releases" if we had a working pg_upgrade, even
> without doing any extra work to allow updates. People who didn't want
> to wait for the next incompatible release could have their change sooner
> if they were willing to do the work to provide an update path.
'K, but let's put the horse in front of the cart ... adopt the policy so
that the work on a working pg_upgrade has a chance of succeeding ... if we
said no on disk changes for, let's say, the next release, then that would
provide an incentive (I think!) for someone(s) to pick up the ball and
make sure that pg_upgrade would provide a non-dump/reload upgrade for it
...
> But the real problem IMHO is we don't have the manpower to do adequate
> testing of back-branch changes that would need to be substantially
> different from what gets applied to HEAD. I think it's best to leave
> that activity to commercial support outfits, rather than put community
> resources into it.
What would be nice is if we could create a small QA group ...
representative of the various supported platforms, who could be called
upon for testing purposes ... any bugs reported get fixed, its finding the
bugs ...
