hi there, folks:
I'd really like to release 0.7.0 but I would like it to be at least a
little bit tested before I do so. Could those of you with CVS trees check
everything out and see if it performs as advertised? Deeper bugs than
that will have to wait for the next release, but I'd at least like to know
if it works for someone other than me.
______ __ __ _____ _ _
| ____ | \_/ |_____] |_____|
|_____| |_____ | | | |
@ t w i s t e d m a t r i x . c o m
A few months ago, the question of an official process for obtaining commit access was raised.
The discussion lead to this proposal - https://twistedmatrix.com/trac/wiki/Proposal/ContributorAdvancementPath <https://twistedmatrix.com/trac/wiki/Proposal/ContributorAdvancementPath>. I like that proposal, but it is still incomplete: to wit, it defines a template for how roles might be defined but does not actually define any roles. It also seems to be a bit overly ambitious, just from the observed reaction of nobody having the time to implement it :).
So I have a proposal for a scaled back process that nevertheless would give us something official-ish:
Not all committers are actively involved in the project at all times, so we should form a "committer committee" of people who are interested in evaluating candidates. If you would like to do that and you're already a committer, please contact me and I'll add you to the list. I want to do this so there's somewhere to apply to which isn't just a public mailing list or discussion, since public discussions can create social pressure to grant someone commit just to be nice, and rejections might be perceived as mean.
Candidates should submit an application to this new list, commit(a)twistedmatrix.com <mailto:email@example.com> which is a list of links to at least 10 tickets, at least 5 of which are patches they've submitted, and at least 5 of which are code reviews they've done which have been accepted by a committer. At least 2 of their authored patches should have gone all the way through the process to be landed.
As with the other parts of our process, if there is at least one sponsor, and no objections from anyone on the committee within 7 days, any member of the committee may add the committer.
New committers should then be announced on the mailing list.
This is not really an ideal process - particularly, it lacks a good way to give contributors something specific and useful to do - but it's something at least. If there is general assent that this is an improvement, I'll go make a wiki page and a mailing list.
Are there any major disadvantages of using pymongo with callInThread
instead of txmongo? I'd like to take advantage of some newer features in
pymongo (unfortunately not available in txmongo) and it's certainly easier
to maintain feature parity using callInThread.
https://twistedmatrix.com/trac/ticket/4759 -- I tried to post as a
comment in the Trac ticket but "SpamBayes determined spam probability
Same issue but w/Linux; I've been hacking around at it for a bit and
found a few things that might be helpful. I am on old twisted
(12.1.0) using a backported protocols.memcache so this could be
Inside epollreactor doPoll() I added sanity checks to log when
_poller.poll() gives us an event flagged for READ on a fd that is
_not_ in self._reads (and similarly with writes). Low and behold,
gobs of hits. Unexpected.
So I took a closer look. It appears to me that _epoll.epoll() is
emitting events that are outside of the flags that epollreactor
carefully registers. Filtering them out in doPoll seems to avoid this
particular traceback but it also breaks the world. At least in my
system this appears to be the expected behavior.
So (to restate and summarize) asserting on addWriter() doesn't do
anything because the Port was added by addReader(). Despite only
being in _reads() and being registered with _epoll.EPOLLIN, doPoll()
is getting write events which it happily passes through to
_doReadOrWrite which checks the event flag, sees it as a _POLL_OUT and
tries to write it.
I'll try the obvious (upgrade twisted to current) and see what happens.
[[https://gist.github.com/jason-kane/18f1516d7c1ef381b35e|Gist of my
Another few months, another Twisted release. This one has a few more Py3 goodies in it!
- twisted.positioning, the rest of twisted.internet.endpoints, KQueueReactor (for real this time), twisted.web.proxy/guard, and Trial (!!!) have all been ported to Python 3.
- Twisted officially supports several more platforms: Py3.4 on FreeBSD, Py2.7/Py3.4 on Fedora 21/22, and Py2.7 on RHEL7.
- Python 2.6 is no longer supported, and support for Debian 6, and RHEL6 has been removed because of this.
- Support for the EOL'd platforms of Fedora 17/18/19 has been removed.
- Twisted has moved to requiring setuptools for installation.
- twisted.python.failure.Failure's __repr__ now includes the exception message.
- 19 tickets in total closed!
As usual, you can find the tarball and newsfile at http://twistedmatrix.com/Releases/pre/15.4.0pre1/ ! Please download them, test them, share them, appreciate them, make them a little nest so that they are comfortable. If there aren't any reported issues, this will be getting a full release soon.
Amber "Hawkie" Brown