Do you QA your Python? Was: 2.1 vs. 2.2

[James Logajan]

Okay, one more post to issue a mea culpa, among other things:

Tim Peters <tim.one at comcast.net> wrote:
> [Paul Rubin]
>> In that particular debate, a lot of people were asking for certain new
>> features to be LEFT OUT of Python. I don't understand how someone can
>> volunteer to contribute work, time, or money toward leaving something
>> out. 
> 
> That was barely mentioned in the "crushing amount of debate over
> 'stability' [that] has gone by on Python-Dev the last week", so I don't
> know what "that particular debate" means to you, but it surely doesn't
> refer to anything in the paragraph you were responding to.

Oops. I also misread Tim's paragraph, hence my other post in this thread 
that makes the same conceptual mistake. Sorry.

>  The debate
> on Python-Dev has about backward compatibility, and especially about
> producing bugfix releases for older releases for a much longer time. 
> Those things take work, and lots of it.  Note that James (to whom I was
> replying) was making the case for why commercial support is important
> to businesses -- nobody is going to buy a support contract that only
> guarantees not to add new features.

Just FYI: This has not been my experience with the motivations I've seen or 
why I've recommended for or against buying support contracts. Many firms 
I've worked with get support contracts to only get bug fixes _and_ priority 
response when problems happen. (E.g. Database systems like Oracle. 
Applications are designed assuming the existing feature set and behavior 
and it is nontrivial to rewrite a mission critical app to take advantage of 
some new feature.) Whether the support contract includes delivery of new 
releases was rarely a consideration. We never bought tools because of their 
future potential, we bought them because we thought they were relatively 
stable and would solve our problems then and there.

>  Quite the contrary, business wants
> bug fixes for older releases, and they *also* want new features in old
> releases, especially in the libraries (like, e.g., SSL support for
> Windows, and support for hot new protocols -- this is a fast-moving
> field, if you haven't noticed <wink>). 

Well, you know business requirements: the product should fit in a shirt 
pocket, have a 23 inch screen, run on a 9V battery for 3 years, and be 
capable of towing your car. ;-) This is why I now always demand a 
_prioritized_ list of requirements from marketing (and they can't all have 
the same priority!)