[Python-Dev] Dropping externally maintained packages (Was:Please stop changing wsgiref on the trunk)

[Tim Peters]

[Tim]
>> In addition, not shown above is that I changed test_wsgiref.py to stop
>> a test failure under -O.  Given that we're close to the next Python
>> release, and test_wsgiref was the only -O test failure, I wasn't going
>> to let that stand.  I did wait ~30 hours between emailing about the
>> problem and fixing it, but I like to whittle down my endless todo list
>> too <0.4 wink>.

[Phillip]
> Your fix masked one of the *actual* problems, which was that
> wsgiref.validate (contributed by Ian Bicking) was also using asserts to
> check for validation failures.  This required a more extensive fix.  (See
> my reply to your problem report.)

No, I didn't mask that.  Two individual tests in test_wsgiref were
failing under -O, and I only fixed one of them (testFileWrapper) at
the time.  In the checkin message for that (rev 46871), I noted that
the other failure (test_simple_validation_error) was due to the coding
of wsgiref.validate, and also noted that extensive changes would be
needed to repair that one.  The failure of the test I did repair was
solely due to code in test_wsgiref.py.

> Your post about the error was on Friday afternoon; I had a corrected
> version on Sunday evening, but I couldn't check it in because nobody told
> me about any of the "ordinary everyday maintenance" they were doing, and I
> had to figure out how to merge the now-divergent trees.

I'm sorry, but I don't think you can expect to get special email about
these never-ending kinds of small changes.  It's not realistic.  They
all show up on the python-checkins list, which you could filter (you
are subscribed to that, right?).

You could also use the svn command I showed last time to get a list of
all checkins that have modified one of your files since the last time
you blessed it.  I know this is possible, since at one point I had to
keep track of random changes to ZODB from copies in umpteen different
branches of Zope2 and Zope3.  I also know it's a PITA ;-)  But AFAIK
you have only _one_ "external copy" to keep track of now, and IME the
pain grew more like the square of the number of external copies (each
pair of external copies effectively had to get compared).

> The whitespace changes I expected, since you previously told me about
> reindent.py.  The other changes I did not expect, since my original message
> about the checkin requested that people at least keep me informed of
> changes (as does PEP 360), so I thought that people would abide by that or
> at least notify me if they found it necessary to make a change to e.g. fix
> a test.

Well, I don't pay any attention to which files reindent.py changes, so
you'll never get special email from me about that.  It looked like
Brett's checkin was the result of some similarly mechanical "look for
code directories that forgot to svn:ignore compiled Python files"
process.  Neal's PyChecker checkin also touched more than one
subproject, and he probably plain forgot that anything with "wsgiref"
in its path was supposed to get special treatment.  These things
simply will happen, and especially in more-or-less mindless cleanup
checkins.

> Your email about the test problem didn't say you were making any changes.

There's also a rule that all tests must pass, and as a release grows
close that gets higher priority.  As I said, I waited about 30 hours,
but got no response and saw no action, so moved it along simply
because it needed to be repaired and I was able to make time for it.
If you hadn't repaired test_simple_validation_error, I would have had
no qualms about hacking in anything to stop that failure too before
the release.  If we had been "far" away from a release, I wouldn't
have done anything here (beyond sending the email).

> Regardless of "everyday maintenance", my point was that I understood one
> procedure to be in effect, per PEP 360.  If nobody's expected to actually
> pay any attention to that procedure, there's no point in having the
> PEP.  Or if "everyday maintenance" is expected to be exempt, the PEP should
> reflect that.

Since that one is the only realistic outcome I can see, I think the
PEP should say so.

> Assuming that everybody knows which rules do and don't count is a non-starter
> on a project the size of Python.

I expect most rules will never be written down, either.  This works
fine so long as people of good will cooperate with liberal doses of
common sense and tolerance.  It doesn't work at all when the process
gets adversarial.  This project's traditional response to that hasn't
been to craft ever-more legalistic rules (in part because nobody will
volunteer for that), but to give the BDFL the last word on everything.
 Alas, that shows signs of not scaling well to dozens of active
developers either.

Short of freezing the code base and dropping support for buggy
platforms like Linux ;-), I don't pretend to have a solution.