[Twisted-Python] The Path to Twisted 14.1

[Glyph]

> On Nov 3, 2014, at 2:43 PM, HawkOwl <hawkowl at atleastfornow.net> wrote:
> 
> Hi everyone,
> 
> To keep everyone in the loop...

Thanks for the update!

> Since 14.0 came out months ago, and we really should have 14.1, I think it’s time we bit the bullet and cleaned out the regressions to get it out the door. Unfortunately, all of the currently open regressions are from the new logging system (#6750, plus #7548 and #7545) Since these regressions are introduced by a new ticket, we should revert them, and get the regressions fixed before it is remerged. I’ll make a new milestone called “New Twisted Logging” or similar so that they’re all still kept track of as a group.
> 
> The only other big thing preventing 14.1 is https://twistedmatrix.com/trac/ticket/7647 , the patch that 14.0.1/14.0.2 was released to include. The patch fixes it, but not ideally, so it needs looking at.
> 
> Once I’ve reverted those tickets and we can get #7647 refined and merged in some form, 14.1 will be out the door :)

I have mixed feelings about this plan.

On the one hand, this is technically the way the policy works: if there's a regression that hasn't been in a release, it's supposed to be reverted.

On the other hand, this is not the way the policy has been enforced in the past.  Particularly, we've rarely done reverts where we had to revert multiple changes which depended upon each other, where regression fixes had already been accepted onto trunk and multiple outstanding branches which had already been through review were pending.  It would be nice if we could just get the regression fixes landed.

On the gripping hand, many of these regressions have been outstanding for months, and so if we could get these fixed promptly enough, presumably we would have done that already.

In favor again of reverting is the fact that no code outside twisted.python.logger or twisted.python.log has been modified to take advantage of the new system, so we're not going to be breaking any dependencies on trunk.

My biggest concern is that this feature was big enough that it dang near broke the review process the first time.  Clearly code review wasn't sufficient to spot these regressions in the first place.  There's no reason to believe that anything but code that lives on trunk for a while is going to flush out these more complex interactions.

Delaying the revert is likely to just make things more painful.  Tempting as it is to suggest, bitter experience has taught me that trying to cram things into a release is a recipe for sadness.  So rather than asking if you could hold off, could I instead make two requests for this feature:

Can please we do reviews of the fixes to the regressions as if they were landing on trunk, and not have this revert re-open the need to review the entire (rather large) change?
If we can manage to get this feature landed again quickly after 14.1, will you have time to do a fast-following 14.2?

-glyph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20141104/0ec78832/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4151 bytes
Desc: not available
URL: </pipermail/twisted-python/attachments/20141104/0ec78832/attachment-0002.bin>