[Twisted-Python] AutobahnPython 0.6.3 - WebSocket compression and more

2013-10-05 Thread Tobias Oberstein 
Hi,

AutobahnPython 0.6.3 was just released to PyPi 
https://pypi.python.org/pypi/autobahn with lots of new features, including 
_WebSocket compression_, an upcoming extension to the WebSocket protocol.

We have seen compression ratios of 2-15x with JSON payload over WebSocket, 
which is great, in particular for mobile and embedded devices / IoT!

AutobahnPython supports WS compression for both clients and servers, and with 
all knobs and options.

Besides AutobahnPython, the extension is currently implemented in Chromium 
(very near shipping in Chrome), WebSocket++ (client and server), pywebsocket 
(server only) and Jetty (server only, not yet released, partial implementation).

Complete list of new features is here:
https://github.com/tavendo/AutobahnPython/blob/master/CHANGELOG.md

/Tobias

PS: should it be frowned upon posting announcements like this, please let me 
know. If it's useful/ok, please let me know also - I am hesitating each time to 
do postings like this to the list ..

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

Re: [Twisted-Python] twisted linux netfilter_log protocol

2013-10-05 Thread David Stainton 
Right. I gave my class one of these: implements(interfaces.IPushProducer,
interfaces.IReadDescriptor)
Which means that I can easily write a class that implements IConsumer
to do something with the packets.

https://github.com/david415/hushVPN/blob/master/nflog_reader.py

This is basically a packet sniffer which receives packets based on iptables
rules.

After that I wrote proxy consumer/producers too; classes that implement
both IConsumer and IPushProducer;
this allows me to transform the packets before sending them to a transport.

I was inspired by this doc:
http://twistedmatrix.com/documents/12.2.0/core/howto/producers.html

So far I really love Twisted!


On Wed, Oct 2, 2013 at 3:14 AM, Phil Mayers  wrote:

> On 02/10/13 09:25, David Stainton wrote:
>
>>
>> In examples of Twisted UDP clients they all do this:
>>
>> reactor.listenUDP(3000,**MyProtocol())
>>
>> What would I do instead?
>> reactor.addReader makes sense to me since what I have is a file
>> descriptor,
>> and the reactor loop and use select or epoll find out when there is data
>> to read...
>> and call our doRead() method of the Reader.
>>
>> I don't know about implementing this as a Protocol because I do not have
>> any
>> equivalent to ReactorUDP. ReactorUDP's listenUDP returns a ListeningPort.
>> And I'm not sure how a Transport is related to my Reader... but it seems
>> to me
>> that there is some abstraction which sets callbacks for io and also
>> calls buildProtocol...
>>
>
> Sorry, maybe I was unclear: you were asking about protocols, so I was
> merely pointing out that *if* you were to use a protocol, you should copy
> the approach DatagramProtocol and udp.Port take.
>
> However as I noted, it *might not* make sense to do this, if there's only
> ever going to be one socket listening on this "thing", your current
> approach might be fine.
>
>
>  If I am going to be using a Twisted Service to drop privileges after
>> gaining access to the fd...
>> How would I do this? Would I have startService() instantiate a Protocol
>> instance?
>>
>
> As above, it depends. If you're using Protocol instances, then yes. If
> not, then no.
>
> Services are just things which start and stop; they may or may not use
> objects implementing the transport/factory/protocol pattern.
>
>
>
>> I don't know about the nflog file descriptor...
>> but the nflog generator interface is non-blocking if used like this:
>>
>
> Ok. Weird API, but if it works...
>
>
>  My nflog reader seems to work great.
>>
>
> If it works for you, and you're using documented Twisted interfaces, then
> there's probably no need to fiddle with it.
>
>
> __**_
> 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] txThings - simple library for CoAP protocol

2013-10-05 Thread Tobias Oberstein 
> I would like to announce the first release of txThings. It is a simple library
> for Constrained Application Protocol (CoAP). CoAP is a relatively new protocol
> designed for "Internet of Things" and M2M communications.

Cool! 

> Internet of Things is currently very interesting field of development. It is
> approaching
> a phase where many opportunities for both large and small players. I think
> Twisted is
> well suited for development of IoT apps:
> - it's stable
> - it's Python based and portable
> - it has good support for UDP and TCP, which makes it ideal for proxying IoT
> protocols to HTTP
> In my opinion in the next three years, at least 20% of Twisted apps will be
> IoT related
> (educated guess, no hard data :) )

I fully agree that Python/Twisted may have a particular competitive
advantage in embedded / IoT (see below).

And if so, why not take that opportunity and actively embrace / promote
specifically IoT from the Twisted community?

Why I think Python/Twisted has an edge:

- the (more pure) Web play languages like PHP and Ruby don't fit well with
processing serial port data or doing UDP (if possible at all)
- Perl - shudder;) Python is easy to approach for beginners and sane and bla
bla bla
- C: is here to stay, and has it's place in IoT
- C++: can't see a particular competitive advantage for IoT
- same goes for (great) stuff like Haskell or Erlang

Whats your take on the stuff below?

There is .NET driven by MS. I wasn't aware that they created a .NET Micro
under _Apache 2.0_ (!):

http://en.wikipedia.org/wiki/.NET_Micro_Framework
http://www.netmf.com/

Then there is Oracle with Java ME
http://www.oracle.com/us/solutions/internetofthings/index.html

Then there is .. JavaScript. Put v8/node on your Pi. However, Node has
quite a different focus. Last time I checked e.g. the support for serial
was not in main project (I had read comments they don't _want_ to have it).

And then there is the Lua universe that has a bunch of brilliant stuff:

http://www.eluaproject.net/
http://luajit.org/
https://github.com/justincormack/ljsyscall

===

If above sounds OT for this list, in one way probably, but when looking from
the angle: competitive advantage of Python/Twisted and opportunities for
expanding the community and actively promoting Twisted, I'd say it's on
topic.

/Tobias


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

[Twisted-Python] txsocksx 1.13.0.0 released (SOCKS clients for Twisted)

2013-10-05 Thread Aaron Gallagher 
Hi!

txsocksx  1.13.0.0 has been
released--the first stable 1.x release.

This version has full implementations of client endpoints which wrap
client endpoints and perform SOCKS 4, 4a, or 5 proxy negotiation.

Additionally, txsocksx comes with support code to allow HTTP requests to
be made over a SOCKS connection using Twisted's Agent API, and another
wrapper endpoint for performing TLS negotiation after proxy negotiation.
(The TLS wrapper endpoint will eventually land in twisted as a part of
, but are experimentally in txsocksx for now.)

Documentation is available on ReadTheDocs, including examples and an API
reference: .

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

Re: [Twisted-Python] AutobahnPython 0.6.3 - WebSocket compression and more

2013-10-05 Thread Glyph 

On Oct 5, 2013, at 7:24 AM, Tobias Oberstein  
wrote:
 
> AutobahnPython 0.6.3 was just released to PyPi 
> https://pypi.python.org/pypi/autobahn with lots of new features, including 
> _WebSocket compression_, an upcoming extension to the WebSocket protocol.

Congratulations, Tobias!  And thanks again for providing support for Twisted in 
Autobahn!

>  PS: should it be frowned upon posting announcements like this, please let me 
> know. If it's useful/ok, please let me know also - I am hesitating each time 
> to do postings like this to the list ..

The official (at least as far as "official" goes) policy on this is that it's 
OK until someone complains, and right now the volume of such announcements is 
not high enough to bother anyone.  And it's nice to see code being released 
that supports Twisted well.  So keep them coming!  If there's ever an issue we 
can always make a separate list for announcements.

-glyph

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

Re: [Twisted-Python] txsocksx 1.13.0.0 released (SOCKS clients for Twisted)

2013-10-05 Thread Glyph 

On Oct 5, 2013, at 6:18 PM, Aaron Gallagher <_...@habnab.it> wrote:

> Hi!
> 
> txsocksx  1.13.0.0 has been
> released--the first stable 1.x release.

Cool!

> This version has full implementations of client endpoints which wrap
> client endpoints and perform SOCKS 4, 4a, or 5 proxy negotiation.
> 
> Additionally, txsocksx comes with support code to allow HTTP requests to
> be made over a SOCKS connection using Twisted's Agent API, and another
> wrapper endpoint for performing TLS negotiation after proxy negotiation.
> (The TLS wrapper endpoint will eventually land in twisted as a part of
> , but are experimentally in txsocksx for now.)

Always great to get some real-world usage while these things make their way 
through code review :-).

> Documentation is available on ReadTheDocs, including examples and an API
> reference: .

I'm super happy to see such widespread use of the endpoint API :-).  It looks 
like there's no endpoint string parser plugin, though; any chance you'll be 
looking into adding that in a future release?

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

Re: [Twisted-Python] txsocksx 1.13.0.0 released (SOCKS clients for Twisted)

2013-10-05 Thread Aaron Gallagher 
Glyph  writes:

> I'm super happy to see such widespread use of the endpoint API :-). It
> looks like there's no endpoint string parser plugin, though; any
> chance you'll be looking into adding that in a future release?

Yes! This is definitely on my todo list, but it will be much more useful
once  (IStreamClientEndpointStringParserWithReactor, which I
need to work on again) and  (quoting for ${x}FromString,
which I just reviewed) land.

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

Re: [Twisted-Python] txThings - simple library for CoAP protocol

2013-10-05 Thread Glyph 
On Oct 5, 2013, at 3:12 PM, Tobias Oberstein  
wrote:

> If above sounds OT for this list, in one way probably, but when looking from
> the angle: competitive advantage of Python/Twisted and opportunities for
> expanding the community and actively promoting Twisted, I'd say it's on
> topic.

While I appreciate showing respect for the list membership's time and trying to 
stay on topic - jeez, lighten up, if you have stuff to say about Twisted, 
please just say it on this list ;-).  The Management will not hesitate to 
(gently, politely) tell you if we believe you've gone too far afield.

-glyph

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

Re: [Twisted-Python] twisted linux netfilter_log protocol

2013-10-05 Thread Glyph 

On Oct 5, 2013, at 10:50 AM, David Stainton  wrote:

> 
> Right. I gave my class one of these: implements(interfaces.IPushProducer, 
> interfaces.IReadDescriptor)
> Which means that I can easily write a class that implements IConsumer
> to do something with the packets.
> 
> https://github.com/david415/hushVPN/blob/master/nflog_reader.py

After a brief glance, this stuff looks pretty cool.  Very much in the spirit 
that these interfaces were developed in.  (And you chose the correct producer 
interface; the other I*Producer interfaces are pretty much just legacy junk, 
sorry about that :-))

One thing to note, though: you should switch to this style:

@implementer(IPushProducer, IReadDescriptor)
class NFLogPacket...

because the implements() style won't work in future versions of Python.  (Plus, 
the implementation of @implementer is much cleaner on older versions too.)

-glyph

> This is basically a packet sniffer which receives packets based on iptables 
> rules.
> 
> After that I wrote proxy consumer/producers too; classes that implement both 
> IConsumer and IPushProducer;
> this allows me to transform the packets before sending them to a transport.
> 
> I was inspired by this doc:
> http://twistedmatrix.com/documents/12.2.0/core/howto/producers.html
> 
> So far I really love Twisted!
> 
> 
> On Wed, Oct 2, 2013 at 3:14 AM, Phil Mayers  wrote:
> On 02/10/13 09:25, David Stainton wrote:
> 
> In examples of Twisted UDP clients they all do this:
> 
> reactor.listenUDP(3000,MyProtocol())
> 
> What would I do instead?
> reactor.addReader makes sense to me since what I have is a file descriptor,
> and the reactor loop and use select or epoll find out when there is data
> to read...
> and call our doRead() method of the Reader.
> 
> I don't know about implementing this as a Protocol because I do not have any
> equivalent to ReactorUDP. ReactorUDP's listenUDP returns a ListeningPort.
> And I'm not sure how a Transport is related to my Reader... but it seems
> to me
> that there is some abstraction which sets callbacks for io and also
> calls buildProtocol...
> 
> Sorry, maybe I was unclear: you were asking about protocols, so I was merely 
> pointing out that *if* you were to use a protocol, you should copy the 
> approach DatagramProtocol and udp.Port take.
> 
> However as I noted, it *might not* make sense to do this, if there's only 
> ever going to be one socket listening on this "thing", your current approach 
> might be fine.
> 
> 
> If I am going to be using a Twisted Service to drop privileges after
> gaining access to the fd...
> How would I do this? Would I have startService() instantiate a Protocol
> instance?
> 
> As above, it depends. If you're using Protocol instances, then yes. If not, 
> then no.
> 
> Services are just things which start and stop; they may or may not use 
> objects implementing the transport/factory/protocol pattern.
> 
> 
> 
> I don't know about the nflog file descriptor...
> but the nflog generator interface is non-blocking if used like this:
> 
> Ok. Weird API, but if it works...
> 
> 
> My nflog reader seems to work great.
> 
> If it works for you, and you're using documented Twisted interfaces, then 
> there's probably no need to fiddle with it.
> 
> 
> ___
> 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] twisted linux netfilter_log protocol

2013-10-05 Thread David Stainton 
I'm glad I found the doc about producers/consumers... I should actually
finish a transport so I can see this thing churn data.
Thanks for pointing out that decorator.



On Sat, Oct 5, 2013 at 8:46 PM, Glyph  wrote:

>
> On Oct 5, 2013, at 10:50 AM, David Stainton 
> wrote:
>
>
> Right. I gave my class one of these: implements(interfaces.IPushProducer,
> interfaces.IReadDescriptor)
> Which means that I can easily write a class that implements IConsumer
> to do something with the packets.
>
> https://github.com/david415/hushVPN/blob/master/nflog_reader.py
>
>
> After a brief glance, this stuff looks pretty cool.  Very much in the
> spirit that these interfaces were developed in.  (And you chose the correct
> producer interface; the other I*Producer interfaces are pretty much just
> legacy junk, sorry about that :-))
>
> One thing to note, though: you should switch to this style:
>
> @implementer(IPushProducer, IReadDescriptor)
> class NFLogPacket...
>
> because the implements() style won't work in future versions of Python.
>  (Plus, the implementation of @implementer is much cleaner on older
> versions too.)
>
> -glyph
>
> This is basically a packet sniffer which receives packets based on
> iptables rules.
>
> After that I wrote proxy consumer/producers too; classes that implement
> both IConsumer and IPushProducer;
> this allows me to transform the packets before sending them to a transport.
>
> I was inspired by this doc:
> http://twistedmatrix.com/documents/12.2.0/core/howto/producers.html
>
> So far I really love Twisted!
>
>
> On Wed, Oct 2, 2013 at 3:14 AM, Phil Mayers wrote:
>
>> On 02/10/13 09:25, David Stainton wrote:
>>
>>>
>>> In examples of Twisted UDP clients they all do this:
>>>
>>> reactor.listenUDP(3000,**MyProtocol())
>>>
>>> What would I do instead?
>>> reactor.addReader makes sense to me since what I have is a file
>>> descriptor,
>>> and the reactor loop and use select or epoll find out when there is data
>>> to read...
>>> and call our doRead() method of the Reader.
>>>
>>> I don't know about implementing this as a Protocol because I do not have
>>> any
>>> equivalent to ReactorUDP. ReactorUDP's listenUDP returns a ListeningPort.
>>> And I'm not sure how a Transport is related to my Reader... but it seems
>>> to me
>>> that there is some abstraction which sets callbacks for io and also
>>> calls buildProtocol...
>>>
>>
>> Sorry, maybe I was unclear: you were asking about protocols, so I was
>> merely pointing out that *if* you were to use a protocol, you should copy
>> the approach DatagramProtocol and udp.Port take.
>>
>> However as I noted, it *might not* make sense to do this, if there's only
>> ever going to be one socket listening on this "thing", your current
>> approach might be fine.
>>
>>
>>  If I am going to be using a Twisted Service to drop privileges after
>>> gaining access to the fd...
>>> How would I do this? Would I have startService() instantiate a Protocol
>>> instance?
>>>
>>
>> As above, it depends. If you're using Protocol instances, then yes. If
>> not, then no.
>>
>> Services are just things which start and stop; they may or may not use
>> objects implementing the transport/factory/protocol pattern.
>>
>>
>>
>>> I don't know about the nflog file descriptor...
>>> but the nflog generator interface is non-blocking if used like this:
>>>
>>
>> Ok. Weird API, but if it works...
>>
>>
>>  My nflog reader seems to work great.
>>>
>>
>> If it works for you, and you're using documented Twisted interfaces, then
>> there's probably no need to fiddle with it.
>>
>>
>> __**_
>> 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
>
>
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] twisted linux netfilter_log protocol

2013-10-05 Thread David Stainton 
Oh and it looks like I should be using these for my proxy classes:

http://twistedmatrix.com/documents/current/api/twisted.protocols.pcp.BasicProducerConsumerProxy.html
http://twistedmatrix.com/documents/current/api/twisted.protocols.pcp.ProducerConsumerProxy.html


On Sat, Oct 5, 2013 at 9:22 PM, David Stainton wrote:

>
> I'm glad I found the doc about producers/consumers... I should actually
> finish a transport so I can see this thing churn data.
> Thanks for pointing out that decorator.
>
>
>
> On Sat, Oct 5, 2013 at 8:46 PM, Glyph  wrote:
>
>>
>> On Oct 5, 2013, at 10:50 AM, David Stainton 
>> wrote:
>>
>>
>> Right. I gave my class one of these: implements(interfaces.IPushProducer,
>> interfaces.IReadDescriptor)
>> Which means that I can easily write a class that implements IConsumer
>> to do something with the packets.
>>
>> https://github.com/david415/hushVPN/blob/master/nflog_reader.py
>>
>>
>> After a brief glance, this stuff looks pretty cool.  Very much in the
>> spirit that these interfaces were developed in.  (And you chose the correct
>> producer interface; the other I*Producer interfaces are pretty much just
>> legacy junk, sorry about that :-))
>>
>> One thing to note, though: you should switch to this style:
>>
>> @implementer(IPushProducer, IReadDescriptor)
>> class NFLogPacket...
>>
>> because the implements() style won't work in future versions of Python.
>>  (Plus, the implementation of @implementer is much cleaner on older
>> versions too.)
>>
>> -glyph
>>
>> This is basically a packet sniffer which receives packets based on
>> iptables rules.
>>
>> After that I wrote proxy consumer/producers too; classes that implement
>> both IConsumer and IPushProducer;
>> this allows me to transform the packets before sending them to a
>> transport.
>>
>> I was inspired by this doc:
>> http://twistedmatrix.com/documents/12.2.0/core/howto/producers.html
>>
>> So far I really love Twisted!
>>
>>
>> On Wed, Oct 2, 2013 at 3:14 AM, Phil Mayers wrote:
>>
>>> On 02/10/13 09:25, David Stainton wrote:
>>>

 In examples of Twisted UDP clients they all do this:

 reactor.listenUDP(3000,**MyProtocol())

 What would I do instead?
 reactor.addReader makes sense to me since what I have is a file
 descriptor,
 and the reactor loop and use select or epoll find out when there is data
 to read...
 and call our doRead() method of the Reader.

 I don't know about implementing this as a Protocol because I do not
 have any
 equivalent to ReactorUDP. ReactorUDP's listenUDP returns a
 ListeningPort.
 And I'm not sure how a Transport is related to my Reader... but it seems
 to me
 that there is some abstraction which sets callbacks for io and also
 calls buildProtocol...

>>>
>>> Sorry, maybe I was unclear: you were asking about protocols, so I was
>>> merely pointing out that *if* you were to use a protocol, you should copy
>>> the approach DatagramProtocol and udp.Port take.
>>>
>>> However as I noted, it *might not* make sense to do this, if there's
>>> only ever going to be one socket listening on this "thing", your current
>>> approach might be fine.
>>>
>>>
>>>  If I am going to be using a Twisted Service to drop privileges after
 gaining access to the fd...
 How would I do this? Would I have startService() instantiate a Protocol
 instance?

>>>
>>> As above, it depends. If you're using Protocol instances, then yes. If
>>> not, then no.
>>>
>>> Services are just things which start and stop; they may or may not use
>>> objects implementing the transport/factory/protocol pattern.
>>>
>>>
>>>
 I don't know about the nflog file descriptor...
 but the nflog generator interface is non-blocking if used like this:

>>>
>>> Ok. Weird API, but if it works...
>>>
>>>
>>>  My nflog reader seems to work great.

>>>
>>> If it works for you, and you're using documented Twisted interfaces,
>>> then there's probably no need to fiddle with it.
>>>
>>>
>>> __**_
>>> 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
>>
>>
>
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] Weekly Bug Summary

2013-10-05 Thread trac 



Bug summary
__
Summary for 2013-09-29 through 2013-10-06
  Opened Closed  Total Change
Enhancements:  2  4    -2
Defects:   3  1695 +2
Tasks: 0  2 89 -2
Regressions:   0  0  1 +0
Total: 5  7   1896 -2

|== Type Changes   |== Priority Changes   |== Component Changes   
|Defect:   +2  |Normal:  -1   |Core:   -2 
|Enhancement:  -2  |Low: -1   |Names:  -1 
|Task: -2 |Trial:  +0 
  |Web:+1 



Total Tickets
Open Tickets



New / Reopened Bugs
__
= Normal =
[#6765] IArgumentType is missing the "optional" attribute (opened by lvh)
defect  core   http://twistedmatrix.com/trac/ticket/6765

[#6766] Support specifying the number of trial jobs via number of CPUs (opened by Julian) (CLOSED, duplicate)
enhancement trial  http://twistedmatrix.com/trac/ticket/6766

[#6767] Add a dev-requirements.txt file (opened by rwall)
enhancement core   http://twistedmatrix.com/trac/ticket/6767

[#6768] Proxy (and reverse proxy) should disconnect when the client disconnects (opened by amluto)
defect  webhttp://twistedmatrix.com/trac/ticket/6768

[#6769] TLS doesn't notify when the handshake is done (opened by amluto) (CLOSED, duplicate)
defect  core   http://twistedmatrix.com/trac/ticket/6769



Closed Bugs
__
= Normal =
[#6685] Replaced usage of dicts with nonsense keys with sets in epoll (opened by Alex, closed by lvh, fixed)
enhancement core   http://twistedmatrix.com/trac/ticket/6685

[#6766] Support specifying the number of trial jobs via number of CPUs (opened by Julian, closed by Julian, duplicate)
enhancement trial  http://twistedmatrix.com/trac/ticket/6766

[#5001] replace call to functions from the string module in twisted.scripts.tap2deb (opened by nueces, closed by thijs, fixed)
enhancement core   http://twistedmatrix.com/trac/ticket/5001

[#6239] Merge `twisted/python/_reflectpy3.py` into `twisted/python/reflect.py` (opened by exarkun, closed by thijs, duplicate)
taskcore   http://twistedmatrix.com/trac/ticket/6239

[#6769] TLS doesn't notify when the handshake is done (opened by amluto, closed by habnabit, duplicate)
defect  core   http://twistedmatrix.com/trac/ticket/6769

[#6684] Replaced usage of dicts with nonsense keys with sets in kqueuereactor (opened by Alex, closed by exarkun, fixed)
enhancement core   http://twistedmatrix.com/trac/ticket/6684

= Low =
[#6563] Replace usage of t.p.compat.reduce in twisted.names (opened by thijs, closed by thijs, fixed)
tasknames  http://twistedmatrix.com/trac/ticket/6563



Ticket Lifetime Stats
__
Oldest open ticket - [#50] conch command-line client doesn't work in win32 (since 2003-07-12 14:41:06).
Newest open ticket - [#6768] Proxy (and reverse proxy) should disconnect when the client disconnects (since 2013-10-03 13:20:15).

Mean open ticket age: 1256 days, 18:40:15.297402.
Median: 1025 days, 13:55:19.480947.
Standard deviation: 974 days, 9:39:25.284665.
Interquartile range: 1570 days, 21:51:19.

Mean time between ticket creation and ticket resolution: 647 days, 14:59:20.890772.
Median: 105 days, 22:34:43.
Standard deviation is 906 days, 2:56:37.400297.
The interquartile range is 1037 days, 15:33:13.

Mean time spent in review: 93 days, 16:51:08.783984.
Median: 4 days, 23:42:15.
Standard deviation: 417 days, 17:41:03.236476.
Interquartile range: 20 days, 16:58:58.

Mean number of times a ticket is reviewed: 1.94734876774.
Median: 1
Standard deviation: 1.54465231534.
Interquartile range: 1.


Contributor Stats
__
In the last 4 weeks,
21 unique ticket reporters
12 unique ticket reviewers
7 unique ticket resolvers
In the last 24 weeks,
73 unique ticket reporters
25 unique ticket reviewers
19 unique ticket resolvers
In the last 48 weeks,
121 unique ticket reporters
37 unique ticket reviewers
31 unique ticket resolvers





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