[Zope-Coders] Re: [Zope-Checkins] CVS: Zope/doc - CHANGES.txt:1.535.2.107

[Chris McDonough]

Every checkin is a point of potential controversy.  Thankfully, we have
a system that allows people who care to be notified of the changes and
have some input on them before a release is made.

FWIW, as a general rule, I always ask myself the question "would *you*
have had a strong opinion about whether this is the right thing or not"?
If the answer is "yes", I ask the question and delay making a checkin. 
If the answer is "no", I just check it in.  In this case, the answer to
myself was "no", for better or worse.

- C

On Sat, 2003-05-17 at 13:20, Tim Peters wrote:
> [Andreas Jung]
> > So what is the sense  to have a policy?  ..and what are the rules
> > to break the policy ? :-)
> 
> I can explain the rule used for Python bugfix releases, but you won't be
> happy with it <wink>:  Every change has pros and cons.  No change is made in
> any release unless the pros exceed the cons.  For a bugfix release, the
> policy against a change in visible behavior adds a big con against such
> changes.  The pros have to strong then to overcome that, much more so than
> in a non-bugfix release, and/or the other cons have to be very weak.
> 
> For example (and these are rare!), in Python 2.2.3 (not yet released),
> Python will support os.fsync() on Windows for the first time.  This is
> really a new feature, and can certainly change the behavior of programs that
> currently branch on hasattr(os, 'fsync').  That con is thought to be very
> weak, since no example of such code is known, and it's an unlikely thing for
> sane code to be doing.  There are other things against it (new docs, new
> tests, possibly unintended behavior on "Windows-like" systems we can't
> test -- any change carries several risks of breakage), but they're minor
> compared to the risk of primary breakage, and the latter is judged as
> insignificantly unlikely.
> 
> The pro is that Zope Corp's FileStorage needs some form of fsync() to
> improve reliability in the face of Windows unreliability, and there's no way
> in 2.2.2 to get at the Windows flavor of fsync() from Python (not short of
> installing the win32 extensions and using the native Win32 API to commit
> system buffers to disk).
> 
> The details there didn't matter, the point is that such decisions always pit
> pros and cons against each other, and are always arguable (e.g., maybe you
> don't think FileStorage reliability is important on Windows, or maybe
> someone else has built a product relying on playing hasattr tricks with the
> os module).
> 
> The sense in having a policy is to favor one usually-right outcome in the
> absence of strong argument against it.  The rule for violating the policy is
> that a strong argument succeeds.  Success or failure in the latter is the
> outcome of a social process, like the one we're engaged in now.  It probably
> would have been better if Chris had discussed the tradeoffs before
> committing the change, though.  "Retroactive discussion" happens in Python
> development too, and I'd say there's about a 50-50 chance that such changes
> get reverted there, usually when someone points out a specific con the
> committer wasn't aware of, or didn't value as highly as most people.
>