On Sat, Mar 3, 2012 at 12:01 AM, Robert Haas <robertmh...@gmail.com> wrote:
> On Fri, Mar 2, 2012 at 4:56 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
>> Checksums patch isn't sucking much attention at all but admittedly
>> there are some people opposed to the patch that want to draw out the
>> conversation until the patch is rejected,
>
> Wow. Sounds like a really shitty thing for those people to do -
> torpedoing a perfectly good patch for no reason.
You've explained to me how you think I do that elsewhere and how that
annoyed you, so I think that topic deserves discussion at the
developers meeting to help us understand one another rather than
perpetuate this.
> I have an alternative theory, though: they have sincere objections and
> don't accept your reasons for discounting those objections.
That's exactly the problem though and the discussion on it is relevant here.
Nobody thinks objections on this patch, checksums or others are made
insincerely. It's what happens next that matters. The question should
be about acceptance criteria. What do we need to do to get something
useful committed? Without a clear set of criteria for resolution we
cannot move forward swiftly enough to do useful things. My thoughts
are always about salvaging what we can, trying to find a way through
the maze of objections and constraints not just black/white decisions
based upon the existence of an objection, as if that single point
trumps any other consideration and blocks all possibilities.
So there is a clear difference between an objection to any progress on
a topic ("I sincerely object to the checksum patch"), and a technical
objection to taking a particular course of action ("We shouldn't use
bits x1..x3 because...."). The first is not viable, however sincerely
it is made, because it leaves the author with no way of resolving
things and it also presumes that the patch only exists in one version
and that the author is somehow refusing to make agreed changes.
Discussion started *here* because it was said "Person X is trying to
force patch Y thru", which is true - but that doesn't necessarily mean
the version of the patch that current objections apply to, only that
the author has an equally sincere wish to do something useful.
The way forwards here and elsewhere is to list out the things we can't
do and list out the things that must change - a clear list of
acceptance criteria. If we do that as early as possible we give the
author a good shot at being able to make those changes in time to
commit something useful. Again, only *something* useful: the full
original vision is not always possible.
In summary: "What can be done in this release, given the constraints discussed?"
So for Peter's patch - what do we need to do to allow some/all of this
to be committed?
And for the checksum patch please go back to the checksum thread and
list out all the things you consider unresolved. In some cases,
resolutions have been suggested but not yet implemented so it would
help if those are either discounted now before they are written, or
accepted in principle to allow work to proceed.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
