Re: [Twisted-Python] Python3 twistd daemon for Ubuntu 14.04 alternatives

[Glyph Lefkowitz]

> On Feb 27, 2017, at 4:05 PM, Clayton Daley  wrote:
> 
> On Sun, Feb 26, 2017 at 1:08 AM, Hynek Schlawack  > wrote:
> 
>> Are you talking about building Docker containers on the fly? 
> 
> I’m a bit baffled what gave you that idea after I’ve spent days arguing for 
> strict build/runtime separation?
> 
> I was just trying to figure out where you were having this problem:
> 
> > ZFS and apt-get + lots of files in a deb = omgiwannamurdersomeone
> 
> I heard the opposite of what you meant by this comment -- that you were 
> deploying apt-gets + debs using docker and the combination had you wanting to 
> murder someone. A really sharp dev wrote our software, but did a poor job 
> sequencing Dockerfiles... and I had that exact same reaction.  My question 
> had nothing to do with build-runtime separation... just docker optimization. 
> On a dev (not ops) list, it didn't seem like a crazy question.

The question as such is not crazy at all, but rather, Hynek has been, both in 
general and repeatedly in this specific thread, a strong proponent of strict 
build & run container separation.  What made the question confusing was that to 
ask it of him, in this way, implied that you weren't following his earlier 
suggestions, and it's not clear what you were reading into them if not "don't 
build containers on the fly".

> Obviously Glyph couldn't answer this question so his interjection came off as 
> condescendingly unhelpful.

It was not my intention to condescend, and I'm sorry that I did; my intention 
was to express a similar sort of bafflement that Hynek did.  My intention was 
for it to be read more like "you must have read the same commitment to build 
and runtime separation that I did in Hynek's posts, so I'm not sure what you're 
referring to".

(Plus, this response was a quip in a longer reply mainly about Pex.)

> Perhaps it's not an impression he deserves, but he got off to a horrible 
> start when he responded to my first ever Twisted question 
> (http://stackoverflow.com/questions/22896993/persisting-data-in-a-twisted-app 
> )
>  without bothering to add anything (sound familiar?).

The right thing to have done (with respect to the site's guidelines) would have 
been to vote to close (as "too broad" or perhaps "primarily opinion based") 
rather than to make that comment.  However, I find that closing users' 
questions, especially relatively those asked by users without much experience 
on the site (i.e.: sub-1k reputation), is often interpreted as a hostile 
dismissal, so I ask for an SSCCE which can guide the asker to a more 
narrowly-constrained question that hews more closely to the guidelines set 
forth on the site.  It really saddens me that a comment is taken as equally 
condescending; short of writing multiple paragraphs of apologetic preface for 
every piece of feedback, it's not clear what a regular answerer on the site 
ought to do.

The fact that nobody else bothered to answer this question, comment on it, or 
even upvote it (one of the 2 upvotes was mine; I tend to upvote questions which 
are otherwise well-asked but need editing for specificity) in the intervening 
two years suggests that my "not appropriate for SO" assessment was accurate.  
What I was trying to tell you was "you aren't going to get any answers with a 
question phrased like this".

One of the reasons I'm responding to this throwaway comment in such detail is 
that this category of misunderstanding - that attempting to be helpful in a 
volunteer endeavor like answering strangers' questions can be interpreted as 
arrogance, dismissal, or hostility (and the grudge nursed for years after the 
fact!), is a significant emotional cost for anyone involved in any form of 
volunteer support for open source.  I'm in the middle of taking a year off from 
answering questions on SO for this exact reason.

So, if you're reading this message, and you're ever mad at someone rejecting 
your question (or your PR or your bug report or whatever), please take a moment 
to consider the transaction from their perspective.  They're commenting in an 
attempt to be helpful, and they've probably just answered 5 (or 10 or 50 or 
100) similar questions, and so they may not be including the full context of 
their feedback.

Ironically, the question you asked on SO would have been great mailing list 
fodder, it just doesn't fit the format stipulated by Stack Overflow's 
guidelines.  The intersection of persistence and Twisted _is_ a subtle and 
non-obvious issue, one that I've personally been trying to help address 
recently (for example) by taking over maintenance of 
http://alchimia.readthedocs.io .

> I rarely interject because I'm no developer... just an entrepreneurial 
> jack-of-all-trades (masters in business, bachelors in business, minor in CS 
> -- albeit from Carnegie Mellon) 

Re: [Twisted-Python] Python3 twistd daemon for Ubuntu 14.04 alternatives

[L. Daniel Burr]

Hi Clayton,

On February 27, 2017 at 6:07:14 PM, Clayton Daley (clayton.da...@gmail.com) 
wrote:

[SNIP]


Obviously Glyph couldn't answer this question so his interjection came off as 
condescendingly unhelpful.  Perhaps it's not an impression he deserves, but he 
got off to a horrible start when he responded to my first ever Twisted question 
(http://stackoverflow.com/questions/22896993/persisting-data-in-a-twisted-app) 
without bothering to add anything (sound familiar?).

I rarely interject because I'm no developer... just an entrepreneurial 
jack-of-all-trades (masters in business, bachelors in business, minor in CS -- 
albeit from Carnegie Mellon) that sometimes contributes to our partly-Twisted 
product.  However, you've succeeded in making my unusual perspective feel most 
unwelcome... so you'll be glad to know that you're never going to have to 
suffer me again.


I think your characterization various parties involved in this thread is 
unfair, and that you are expressing an inappropriate sense of entitlement.  
Enumerating your academic degrees in no way enhances any point you are trying 
to make here, and strikes me as argument from authority.  It is a shame that 
some miscommunication has occurred, and I think a more positive outcome could 
be achieved if you’d walk back a few of these remarks and re-engage.

L. Daniel Burr___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Removing support for old Python 3 versions

[Glyph Lefkowitz]

Perhaps we should add a Raspbian builder if this is a platform of interest to 
Twisted users.  (And I do think it should be.)

Are there big / fast raspberry pi emulators so we don't need to wait for the 
test suite to run on such a slow / small machine?

> On Feb 27, 2017, at 3:38 PM, Tom Most  wrote:
> 
> Yes, this is what my Raspbian system reports:
> 
> Python 3.4.2 (default, Oct 19 2014, 13:31:11) 
> [GCC 4.9.1] on linux
> 
> ---Tom
> 
> On Fri, Feb 24, 2017 at 6:01 PM, Glyph Lefkowitz  > wrote:
> 
>> On Feb 24, 2017, at 3:29 PM, Tom Most > > wrote:
>> 
>> On Thu, Feb 23, 2017 at 1:30 AM, Glyph Lefkowitz > > wrote:
>> 
>> Is there a "pre-installed on hardware that's hard to change" issue here?  Do 
>> Raspbian users generally upgrade to new stable releases?
>> 
>> -g
>> 
>> There's also a substantial lag after a Debian release before the 
>> corresponding version of Raspbian becomes generally available. Debian Jessie 
>> was released April 2015, but Raspbian Jessie looks to have gone GA in 
>> September[1] (though you could get it sooner by adjusting your apt sources).
>> 
>> [1]: https://www.raspberrypi.org/blog/raspbian-jessie-is-here/ 
>> 
> 
> So Jesse (== CPython 3.4) is still what's current for Raspbian users?
> 
> -glyph
> 
> ___
> Twisted-Python mailing list
> Twisted-Python@twistedmatrix.com 
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python 
> 
> 
> 
> ___
> Twisted-Python mailing list
> Twisted-Python@twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Test coverage requirements

[Glyph Lefkowitz]

> On Feb 27, 2017, at 3:33 PM, Jean-Paul Calderone  
> wrote:
> 
> On Mon, Feb 27, 2017 at 6:00 PM, Tristan Seligmann  > wrote:
> On Mon, 27 Feb 2017 at 21:54 Glyph Lefkowitz  > wrote:
> That said, it has been improving and if it keeps improving at the rate it has 
> been, I expect that we'd be able to put that coverage blocker back in in 
> another 3-4 months.  Perhaps something to talk about at PyCon.
> 
> I think at least one problem that we're suffering from here is our fault, 
> rather than Codecov's: the coverage of the test suite is not stable due to 
> non-determinism in the test suite. That is, the lines executed during a test 
> run are not the same every time due to things like ordering / timing races / 
> etc. This means that "changes" to coverage may show up for a particular 
> PReven though nothing in that PR is actually responsible.
> 
> 
> Changes to Twisted code which are only sometimes covered by the test suite 
> sound like they would violate a 100% coverage rule.  But I guess the 
> experience of looking at a codecov report is so bad/confusing that it's not 
> surprising authors/reviewers might fail to see what's going on and fix the 
> non-deterministic.
> 
> Particularly for code that requires coverage measurements on multiple 
> platforms (ie, you basically can't do it locally), it seems like it would be 
> easier (though, to be clear, bad) to just forget about it and hope everything 
> is covered...
> 
> A tool that pointed out coverage differences between multiple runs of the 
> same version of the code would be a useful thing to start pointing out where 
> these flaws in the Twisted test suite lie, right?  And then each area could 
> be given deterministic test coverage instead...

While this is certainly an issue, I don't think it's the issue we're discussing 
here.  Unreliability of coverage is largely mitigated by the fact that the main 
thing we pay attention to is "patch coverage", which can be seen to fluctuate 
from commit to commit on a branch if the new test coverage is non-deterministic 
(and rarely is a PR an individual commit).  This is opposed to "coverage 
delta", which only looks at coverage before / coverage after and is indeed 
somewhat unpredictable due to old / bad tests.

So I can say when I've had to overrule codecov, it's almost never been because 
of flapping coverage lines outside of the patch under consideration (and the 
patches in consideration either have deterministic tests, or I ask the author 
to add them).

General improvements to build reliability often reduce coverage unreliability 
as well, so as we've been using Github more, which surfaces status visibility / 
mergeability to reviewers more, we've been fixing lots of little 
build-reliability issues and this problem continues to get smaller.

-glyph

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Removing support for old Python 3 versions

[Tom Most]

Yes, this is what my Raspbian system reports:

Python 3.4.2 (default, Oct 19 2014, 13:31:11)
[GCC 4.9.1] on linux

---Tom

On Fri, Feb 24, 2017 at 6:01 PM, Glyph Lefkowitz 
wrote:

>
> On Feb 24, 2017, at 3:29 PM, Tom Most  wrote:
>
> On Thu, Feb 23, 2017 at 1:30 AM, Glyph Lefkowitz 
> wrote:
>
>>
>> Is there a "pre-installed on hardware that's hard to change" issue here?
>> Do Raspbian users generally upgrade to new stable releases?
>>
>> -g
>>
>
> There's also a substantial lag after a Debian release before the
> corresponding version of Raspbian becomes generally available. Debian
> Jessie was released April 2015, but Raspbian Jessie looks to have gone GA
> in September[1] (though you could get it sooner by adjusting your apt
> sources).
>
> [1]: https://www.raspberrypi.org/blog/raspbian-jessie-is-here/
>
>
> So Jesse (== CPython 3.4) is still what's current for Raspbian users?
>
> -glyph
>
> ___
> Twisted-Python mailing list
> Twisted-Python@twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>
>
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Test coverage requirements

[Jean-Paul Calderone]

On Mon, Feb 27, 2017 at 6:00 PM, Tristan Seligmann 
wrote:

> On Mon, 27 Feb 2017 at 21:54 Glyph Lefkowitz 
> wrote:
>
>> That said, it has been *improving* and if it keeps improving at the rate
>> it has been, I expect that we'd be able to put that coverage blocker back
>> in in another 3-4 months.  Perhaps something to talk about at PyCon.
>>
>
> I think at least one problem that we're suffering from here is our fault,
> rather than Codecov's: the coverage of the test suite is not stable due to
> non-determinism in the test suite. That is, the lines executed during a
> test run are not the same every time due to things like ordering / timing
> races / etc. This means that "changes" to coverage may show up for a
> particular PReven though nothing in that PR is actually responsible.
>
>
Changes to Twisted code which are only sometimes covered by the test suite
sound like they would violate a 100% coverage rule.  But I guess the
experience of looking at a codecov report is so bad/confusing that it's not
surprising authors/reviewers might fail to see what's going on and fix the
non-deterministic.

Particularly for code that requires coverage measurements on multiple
platforms (ie, you basically *can't* do it locally), it seems like it would
be easier (though, to be clear, *bad*) to just forget about it and hope
everything is covered...

A tool that pointed out coverage differences between multiple runs of the
same version of the code would be a useful thing to start pointing out
where these flaws in the Twisted test suite lie, right?  And then each area
could be given deterministic test coverage instead...
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Test coverage requirements

[Tristan Seligmann]

On Mon, 27 Feb 2017 at 21:54 Glyph Lefkowitz 
wrote:

> That said, it has been *improving* and if it keeps improving at the rate
> it has been, I expect that we'd be able to put that coverage blocker back
> in in another 3-4 months.  Perhaps something to talk about at PyCon.
>

I think at least one problem that we're suffering from here is our fault,
rather than Codecov's: the coverage of the test suite is not stable due to
non-determinism in the test suite. That is, the lines executed during a
test run are not the same every time due to things like ordering / timing
races / etc. This means that "changes" to coverage may show up for a
particular PReven though nothing in that PR is actually responsible.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] trac spam

[Glyph Lefkowitz]

> On Feb 27, 2017, at 5:49 AM, Jean-Paul Calderone  
> wrote:
> 
> On Mon, Feb 27, 2017 at 8:41 AM, Adi Roiban  > wrote:
> On 27 February 2017 at 12:59, Jean-Paul Calderone
> > wrote:
> > Tickets 9058 and 9059 are spam.  I would have cleaned them up but it's not
> > clear from the UI how (actually I clicked a "delete" button in the UI but
> > the tickets are there so I guess "delete" doesn't mean what I think).
> 
> I have removed the first one.
> 
> After you click delete, you need to scroll and to confirm the action.
> 
> I left the other one there as an exercise :)
> 
> Hm I thought I clicked the button at the bottom.  Maybe I was on the wrong 
> page?  Which admin page should I be on?

For now, I've deleted the offending ticket.

You shouldn't be on an "admin" page, per se - if you have the relevant 
permissions, you should see the "delete" button on the ticket itself, and then 
there's a confirmation page.

-glyph

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Test coverage requirements

[Glyph Lefkowitz]

> On Feb 26, 2017, at 3:51 PM, Jean-Paul Calderone  
> wrote:
> 
> Hi,
> 
> I'm looking at some  recent 
>  trunk 
>  commits 
>  (also, others) that seem to 
> have non-trivial untested code at at ReviewProcess 
> .
>   I can't tell if the codecov reports are wrong or if the development process 
> documentation is wrong or if the commits just violate policy or (I guess) 
> some mix of the three.
> 
> Can anyone shed any light on this?

Thanks, JP.  Your habit of post-hoc commit review really helps keep the process 
honest - I wish more folks (myself included) had more time for it!

I wasn't party to most of these changes, except for 432, where I can say based 
on local testing I was very clear that coverage was not in fact an issue, and 
codecov was misreporting it.  So I can't comment on most of them specifically.

Generally though, I can say that Codecov, while more reliable than coveralls, 
is unfortunately really flaky.  (Case in point, right now, clicking on all the 
URLs you posted here, I just see "AccessDeniedAccess Denied" followed by a long 
64-bit identifier which I'm not pasting here for fear that it's some kind of 
github credential.)  Its general unreliability is the main reason we removed 
the hard coverage requirement that blocked merging.

That said, it has been improving and if it keeps improving at the rate it has 
been, I expect that we'd be able to put that coverage blocker back in in 
another 3-4 months.  Perhaps something to talk about at PyCon.

-glyph

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] catching twisted pyqt segmentation fault

[Glyph Lefkowitz]

In general, detecting segfaults in arbitrary processes on the system probably 
isn't possible.

Specifically, I looked up the docs for you ;).

Attach a handler to the QWebEngineView::renderProcessTerminated signal :).

https://doc.qt.io/qt-5/qwebengineview.html#renderProcessTerminated 


Hope this helps,

-glyph

> On Feb 26, 2017, at 11:16 AM, Kevin Mcintyre  wrote:
> 
> Thanks glyph - really appreciate all the times you've answered my questions!
> 
> QtWebEngineView is running a subprocess.
> 
> /home/ubuntu/Qt5.8.0/5.8/gcc_64/libexec/QtWebEngineProcess --type=renderer 
> --disable-accelerated-video-decode --disable-gpu-memory-buffer-video-frames 
> --enable-threaded-compositing --use-gl=desktop --disable-webrtc-hw-encoding 
> --primordial-pipe-token=032B94B57A61DAE34BD0F90551F9ABB6 --lang=en-US 
> --enable-pinch --num-raster-threads=2 --content-image-texture-target=3553
> 
> QT can sometimes be helpful, but bug resolution can take a while.
> 
> Any suggestions outside of twisted for detecting segfaults?  I'm thinking 
> just to monitor /var/log/syslog 
> 
> 
> 
> 
> 
> On Sat, Feb 25, 2017 at 11:59 PM, Glyph Lefkowitz  > wrote:
> 
> > On Feb 25, 2017, at 4:41 PM, Kevin Mcintyre  > > wrote:
> >
> > I have a long running twisted pyqt process which occasionally throws a 
> > Received signal 11.
> >
> > I believe it's in the underlying QtWebEngineView since the twisted process 
> > continues to run.  Whatever the reason I would like to figure out a way to 
> > catch this and stop the reactor either in process, or by another process 
> > monitor.  Any suggestions either twisted or otherwise would be greatly 
> > appreciated.
> 
> Presumably the QtWebEngineView is running a subprocess, then?  This is really 
> a Qt question rather than a Twisted question, because the QtWebEngineView 
> should be emitting some kind of signal when its rendering process crashes.  
> (If it doesn't I imagine you're just out of luck here and you should report a 
> bug to the Qt developers...)
> 
> -glyph
> ___
> Twisted-Python mailing list
> Twisted-Python@twistedmatrix.com 
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python 
> 
> 
> ___
> Twisted-Python mailing list
> Twisted-Python@twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] trac spam

[Jean-Paul Calderone]

On Mon, Feb 27, 2017 at 8:41 AM, Adi Roiban  wrote:

> On 27 February 2017 at 12:59, Jean-Paul Calderone
>  wrote:
> > Tickets 9058 and 9059 are spam.  I would have cleaned them up but it's
> not
> > clear from the UI how (actually I clicked a "delete" button in the UI but
> > the tickets are there so I guess "delete" doesn't mean what I think).
>
> I have removed the first one.
>
> After you click delete, you need to scroll and to confirm the action.
>
> I left the other one there as an exercise :)
>

Hm I thought I clicked the button at the bottom.  Maybe I was on the wrong
page?  Which admin page should I be on?

Jean-Paul



>
> > Jean-Paul
> >
> >
> > ___
> > Twisted-Python mailing list
> > Twisted-Python@twistedmatrix.com
> > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
> >
>
>
>
> --
> Adi Roiban
>
> ___
> Twisted-Python mailing list
> Twisted-Python@twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] trac spam

[Adi Roiban]

On 27 February 2017 at 12:59, Jean-Paul Calderone
 wrote:
> Tickets 9058 and 9059 are spam.  I would have cleaned them up but it's not
> clear from the UI how (actually I clicked a "delete" button in the UI but
> the tickets are there so I guess "delete" doesn't mean what I think).

I have removed the first one.

After you click delete, you need to scroll and to confirm the action.

I left the other one there as an exercise :)

> Jean-Paul
>
>
> ___
> Twisted-Python mailing list
> Twisted-Python@twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>



-- 
Adi Roiban

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] trac spam

[Jean-Paul Calderone]

Tickets 9058 and 9059 are spam.  I would have cleaned them up but it's not
clear from the UI how (actually I clicked a "delete" button in the UI but
the tickets are there so I guess "delete" doesn't mean what I think).

Jean-Paul
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Test coverage requirements

[Adi Roiban]

On 26 February 2017 at 23:51, Jean-Paul Calderone
 wrote:
> Hi,
>
> I'm looking at some recent trunk commits (also, others) that seem to have
> non-trivial untested code at at ReviewProcess.  I can't tell if the codecov
> reports are wrong or if the development process documentation is wrong or if
> the commits just violate policy or (I guess) some mix of the three.
>
> Can anyone shed any light on this?

Besise https://codecov.io/gh/twisted/twisted/pulls/509/diff, the other
PRs looks OK and with good coverage.

In terms of codecov.io coverage I am using the "diff" view as I find
it less confusing.

The strong red lines are the ones which codecov considered that were
part of the patch and were not covered.
The yellow lines are for missing branch coverage in this patch... and
they will decrease the coverage percentage.

In summary:

For PR 509 - The diff coverage is 74.39%. ... this looks bad
For PR 652 -  The diff coverage is 98.7% ... not perfect, but pretty
good as the missing lines are in the test code area :)



At some point we had a commit status check for 100% diff coverage, but
I remember that it was not popular.

If we are not aiming for the ultimate quality dev process we can still
consider having a lower barer of something like 75% or 95% diff
coverage... For PR less of this value, you will see a big warning...
but people from the Twisted admin team can still commit them. Simple
(non-admin) collaborators can only merge them of the diff coverage is
above that limit.

I am for a check for 100% coverage as many times it helped me get out
of comfort zone and "forced" to write better tests  and better code
... I know that libertarians might not like being forced to do things
so I understand why the hard check was not popular.

--

For the good PRs which were mentioned here

For https://codecov.io/gh/twisted/twisted/pulls/695/diff the only line
without a coverage is the one in which the exception is raised if the
reactor is installed twice.

For https://codecov.io/gh/twisted/twisted/pulls/652/diff the uncovered
lines are the case in which a tests is is not skipped on OSX (this is
strange ... but maybe osx coverage are no longer published) ... and
the other one is the self.fail which is expected not be be called.

I think there was a discussion about covering self.fail() calls by
extracting them into assertion helper and making sure we have tests
for those assertion helpers so that we can ask all changes to also
have 100% test code coverage :)

For https://codecov.io/gh/twisted/twisted/pulls/432/diff there were
some changes in formatting (some parenthesis) which were indented and
that code was not previously covered ... so now it is considered code
on which someone made a change without having the tests to cover the
changes.

-- 
Adi Roiban

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python