Re: [Twisted-Python] The Path to Twisted 14.1
On Nov 5, 2014, at 3:54 AM, Glyph gl...@twistedmatrix.com wrote: On Nov 4, 2014, at 7:44 PM, Itamar Turner-Trauring ita...@itamarst.org mailto:ita...@itamarst.org wrote: On 2014-11-03 23:10, Glyph wrote: 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. Except for the fact that Twisted trunk is unusable on Python 3. I don't follow. Are you saying that logger fixed some python 3 stuff, and by reverting it we're losing that, or that log regressed after 14.0 and logger fixed it and that by reverting it we are regressing with respect to its usability in 14.0? On second thought, a more appropriate question: What's the link to the ticket? :) -glyph smime.p7s Description: S/MIME cryptographic signature ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] The Path to Twisted 14.1
On 11/04/2014 09:54 PM, Glyph wrote: I don't follow. Are you saying that logger fixed some python 3 stuff, and by reverting it we're losing that, or that log regressed after 14.0 and logger fixed it and that by reverting it we are regressing with respect to its usability in 14.0? Logger broke installation on Python 3; Twisted trunk is unusable on Python 3 because of logger. It's a breakage that can be easily fixed (one of the modules isn't on the list of things to be installed) but it's incorrect to say that logger didn't break existing code. ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] The Path to Twisted 14.1
http://twistedmatrix.com/trac/ticket/7563 ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] The Path to Twisted 14.1
On 5 Nov, 11:57 pm, ita...@itamarst.org wrote: On 11/04/2014 09:54 PM, Glyph wrote: I don't follow. Are you saying that logger fixed some python 3 stuff, and by reverting it we're losing that, or that log regressed after 14.0 and logger fixed it and that by reverting it we are regressing with respect to its usability in 14.0? Logger broke installation on Python 3; Twisted trunk is unusable on Python 3 because of logger. It's a breakage that can be easily fixed (one of the modules isn't on the list of things to be installed) but it's incorrect to say that logger didn't break existing code. This sub-thread seems to be based on a misreading/misunderstanding of an earlier statement. This one, I think: 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. I don't think it has been suggested that logger didn't break anything (in fact, clearly it broke many things - that's why it's being reverted ;). Instead, Glyph was just commenting that removing logger doesn't have particularly far-reaching consequences throughout Twisted because none of Twisted has been updated to use the new API instead of the old API. Jean-Paul ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] The Path to Twisted 14.1
On 4 Nov 2014, at 12:10, Glyph gl...@twistedmatrix.com wrote: 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. This is mainly why I am in favour of this plan. They’re not small fixes, so we can’t just mop them up in a day. 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. *cough* 14.0 *cough* :) 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? How are we going to manage this? Do we need an “alternate” branch, which consists of #6750 + all the regression fixes, and the “review” is making sure that all of the known regressions are fixed? Or do we remerge it as a “private” API, maybe, so that we can still fit it mostly into our dev process? Or do we do a tubes and just spin it off into another thing of its own, then merge it when it’s finished? I’m not sure. • 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? As long as it’s not the 22nd of November or the weekend of the 7th of Dec (the former of which will be spent in a drunk stupor and the latter is my birthday), I can do it no problem. - hawkie signature.asc Description: Message signed with OpenPGP using GPGMail ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] The Path to Twisted 14.1
On Nov 4, 2014, at 10:38 AM, HawkOwl hawk...@atleastfornow.net wrote: • 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? How are we going to manage this? Do we need an “alternate” branch, which consists of #6750 + all the regression fixes, and the “review” is making sure that all of the known regressions are fixed? Or do we remerge it as a “private” API, maybe, so that we can still fit it mostly into our dev process? Or do we do a tubes and just spin it off into another thing of its own, then merge it when it’s finished? I’m not sure. My idea would be to have a new 6750 branch, and have each regression branch be rebased off of that; then, each review would be merging an individual regression fix into new-6750, and finally, when they're all fixed, landing new-6750 on trunk with no new review provided all buildbots pass. • 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? As long as it’s not the 22nd of November or the weekend of the 7th of Dec (the former of which will be spent in a drunk stupor and the latter is my birthday), I can do it no problem. I figured you could be accommodating, but thanks a lot for confirming! -glyph smime.p7s Description: S/MIME cryptographic signature ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] The Path to Twisted 14.1
On 4 Nov 2014, at 18:07, Glyph gl...@twistedmatrix.com wrote: On Nov 4, 2014, at 10:38 AM, HawkOwl hawk...@atleastfornow.net wrote: • 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? How are we going to manage this? Do we need an “alternate” branch, which consists of #6750 + all the regression fixes, and the “review” is making sure that all of the known regressions are fixed? Or do we remerge it as a “private” API, maybe, so that we can still fit it mostly into our dev process? Or do we do a tubes and just spin it off into another thing of its own, then merge it when it’s finished? I’m not sure. My idea would be to have a new 6750 branch, and have each regression branch be rebased off of that; then, each review would be merging an individual regression fix into new-6750, and finally, when they're all fixed, landing new-6750 on trunk with no new review provided all buildbots pass. That seems logical to me. • 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? As long as it’s not the 22nd of November or the weekend of the 7th of Dec (the former of which will be spent in a drunk stupor and the latter is my birthday), I can do it no problem. I figured you could be accommodating, but thanks a lot for confirming! :) -hawkie signature.asc Description: Message signed with OpenPGP using GPGMail ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] The Path to Twisted 14.1
On 2014-11-03 23:10, Glyph wrote: 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. Except for the fact that Twisted trunk is unusable on Python 3. ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] The Path to Twisted 14.1
On Nov 4, 2014, at 7:44 PM, Itamar Turner-Trauring ita...@itamarst.org wrote: On 2014-11-03 23:10, Glyph wrote: 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. Except for the fact that Twisted trunk is unusable on Python 3. I don't follow. Are you saying that logger fixed some python 3 stuff, and by reverting it we're losing that, or that log regressed after 14.0 and logger fixed it and that by reverting it we are regressing with respect to its usability in 14.0? -glyph smime.p7s Description: S/MIME cryptographic signature ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
[Twisted-Python] The Path to Twisted 14.1
Hi everyone, To keep everyone in the loop... 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 :) - hawkowl signature.asc Description: Message signed with OpenPGP using GPGMail ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] The Path to Twisted 14.1
On Nov 3, 2014, at 2:43 PM, HawkOwl hawk...@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 smime.p7s Description: S/MIME cryptographic signature ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
