On Thu, Jul 14, 2005 at 02:41:13PM +1000, Neil Conway wrote:
> David Fetter wrote:
> >As background, I'd like to go over our policy of, "The code patch
> >must be accompanied by any doc patches that it implies."
>
> Although it is worth noting this policy is not religiously followed
> anyway (e.g. the recent roles patch). I think we basically assume
> that the person contributing a code patch is on the hook to write
> the docs at some point before the next release, unless they can
> convince someone else to do it for them.
A similar, but not *that* similar thing could work for pg_upgrade
components. That's because the skill set for patching C code is more
similar to the skill set for making pg_upgrade components than it is
to the skillset for writing doc patches. I'm guessing, but I'm pretty
sure I'm right here.
For example, I've documented (and had accepted) a fair number of
things whose implementation details I still don't understand, but I
suspect that I'd be out of the pool as far as making pg_upgrade
components.
> >Where the rule now reads,
> >
> > The code patch must be accompanied by any doc patches that it implies.
> >
> >It should read,
> >
> > The code patch must be accompanied by any doc patches *and any needed
> > upgrade transformations* that it implies.
>
> I think this misses the point. The hurdle that needs to be cleared
> for pg_upgrade is to write the infrastructure needed to migrate the
> system catalogs and data directories from one release to another in
> a reliable way.
What work has been done to this end?
Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778
Remember to vote!