Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > I say this because I found at least one such change -- REL7_0_PATCHES,
> > unlike 7.0.2, has an '--enable-syslog' configure switch.
> That's probably the only one, since by back-patching it Marc was
> violating one of our standard rules: no new features in dot-releases,
> only bug fixes.
If I may be so bold, this isn't the first time that rule has been
violated, and, it probably won't be the last. And for many things it
would be an issue -- but this one isn't, if it's the only one, or if
changes are in this ilk. It's the feature changes that haven't been
beta-tested properly that directly affect operations that worry me --
and those are rare. And the USE_SYSLOG feature itself, even without a
--enable-syslog, has been beta tested pretty thoroughly (and fixed a
couple of times, most notably with the syslog message splitter that,
IIRC, Hiroshi added).
But I'm not complaining -- the addition of --enable-syslog makes my job
a little easier, as I now don't need to have that particular prepatch to
config.h.in (which patch I loathed making) to enable USE_SYSLOG for the
RPM's. Of course, making my job easier doesn't necessarily make it
right :-).
> To spread blame around fairly ;-), I'm afraid a lot of my own back-patch
> log entries just say something like "backpatch FOO" without much detail.
> There's more detail in the corresponding log entry in the development
> branch, but to get that, you'll need to run cvs2cl without a branch
> restriction. Sorry...
IOW, the cvs logs (or cvs2cl output) will really have to be gone through
by hand to really get a changelist from 7.0.2 to 7.0.3 instead of a
changelist from 7.0.2 to CURRENT.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
