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 [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend