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
I am restarting this discussion
I am starting a new thread since I want to keep the focus on the
review process / workflow / markers, and not on the things required to
accept a PR or do a review.
> Proposing: Just open a pull request. Any open pull request should be treated as part of the queue.
I don't like this. If you are not a comitter, you need to open a PR to
trigger the tests.
So you want to first open a PR, then wait for tests to execute, then
fix and only after that to request the review.
We can start with setting the title to have "[WIP]" marker, to let
others know that this is not yet ready... but then when changes are
required, the reviewer will have to set the WIP marker again.. and if
the reviewer is not a team member, it will not have rights to edit the
But I hope that we can have a bot which once a "please review" comment
is left, it will set a label.
> Accepting: A committer pushes the big green button;
+1 ... but maybe also leave a comment :)
> Reviewing: This is the potentially slightly odd part. I believe a review that doesn't result in acceptance should close the PR. We need to be careful to always include some text that explains that closing a PR does not mean that the change is rejected, just that the submitter must re-submit. Initially this would just mean opening a new PR, but Mark Williams is working on a bot to re-open pull requests when a submitter posts a "please review" comment: https://github.com/markrwilliams/txghbot
Since we will have a bot for "please review", why not use the same bot
to set a label on "please make changes" ?
I think that closing a PR should mean that the work on that branch is
> Responding: A submitter can open a new PR, or, once we start running txghbot, reopen their closed PR.
As commented above, I am +1 for leaving a "please review" comment and
having a bot updating the labels.
> Viewing: https://github.com/twisted/twisted/pulls?utf8=✓&q=is%3Apr+is%3Aopen+-status…
One we get the "please-review" and "changes-needed" labels it should
be eaiser to view the queue.
Whem multiple reviewers are required, you can use the dedicated GitHub
Review message and approve it without hiting the merge button.
I have no idea how other projects are managing the review queue.
Please send your feedback.
If we agree on a process based on managing the labes, I can work on
implemeting the required logic with a bot and GitHub hooks.
We can also start by using the WIP marker
* while preparing the PR
* once changes are required and the author works on addressing the
changes requsted on review
Any PR which is open and does not have the WIP marker means that is
part of the queue.
PS: I have checked pyca/crypography but I don't see any pattern there
and a lot of PR are merged without any comment
I would like to re-start the conversation about migrating Trac tickets
to GitHub issues.
My main reason for doing this is to make it easier for people to
contribute to Twisted.
In CONTRIBUTING there is this info
`GitHub doesn't provide adequate tooling for its community.`
I don't know what is missing in GitHub and why overall Trac is better
than GitHub issues.
I know that GitHub Issues is simple and you can't save reports.
What are problems are there with GitHub issues, which are blocking the
Please send your thoughts.
Why you think that GitHub issues might be worst than Trac tickets :) ?
Below are the things that I things we will lose when migrating to
GitHub Issues and which will require extra work.
1. We will no longer get the nice ticket reports.
I don't know how to get something like this just using GitHub... and I
think that we will need a separate web page which uses GitHub API to
create the reports.
2. We might lose the owners / authors of some comments as there might
not be a maping from Trac to GitHub. This might be mititage as we are
already using GitHub for login.
3. There is extra one-time work required to do the actual migration,
and decide how to translate Trac ticket attributes to GitHub Issue
We might not get consensus on how to migrate the metadata and this can
be a blocker.
4. We will no longer get the weekly reports and need more work to
reimplement them based on GitHub.
5. Highscores will stop counting the contribution, and it needs more
work to reimplement it on top of GitHub. I have hacked the highscores
project and I can change it to work both historic Trac data and new
Below are my arguments for migrating to GitHub issues:
1. With Twisted tickets/PR only handled on GitHub you can have
contributions which are done only by sending a PR, without creating an
issue. You find a bug, you fix it and send a PR.
You no longer need to go to Trac and create a ticket and then do all
the cross-links copy and pasting.
2. We no longer have the review history in Trac, and the review
discussions are split between Trac and GitHub.
I think that in the future we will move more review discussions in GitHub.
Having all the discussion in a single place will make it easier to
search for something.
You no longer need to search GitHub and Trac tickets.
3. With tickets on GitHub we should simplify the infrastructure.
I feel that lately there was not much time from current Twisted dev to
take care of Twisted infra.
>From what I can see, the servers are just restarted on an issue, but
there is no time to investigate what is wrong.
I think that Twisted dev should focus on Twisted code and not spend
time with the ticketing infrastructure.
4. With tickets in GitHub, we don't need extra tooling to close a
ticket when a PR is merged.
5. With tickets in GitHub I assume that a lot of contributors will
only have to care about a single management tool: GitHub.
They will no longer have to learn about Trac, how Trac keywords work
for a ticket and how a workflow is implemented in Trac for Twisted.
>From what I can see, we are not using the Trac workflows anyway, just
a hack to implementing something like a workflow by manually setting
various attributes of a ticket.
PS: For my private project I am still using Trac for issues and
GitHub for PR and manage the tools to keep them in sync.
I am using the Trac ticket workflows with a dedicated state for a
ticket when it needs a review or when a review was done and it needs
FYI, I opened https://twistedmatrix.com/trac/ticket/9292 which seeks to
realign our theory (what we say in CONTRIBUTING) and what we do in practice
regarding pull requests on GitHub. Please comment on the ticket if you see
The main ticket is here https://twistedmatrix.com/trac/ticket/9288
But the main discussion is on the PR.
I am writing this email, as a notification. Please follow up over PR.
The bug is:
When you have a long-running request, (more than the sessionTimeout)
and you want to get the session at the end of the request, you get an
error like `twisted.internet.error.AlreadyCalled: Tried to cancel an
The possibilities for fixing this (as described by Exarkun):
1. You get back the same Session object as you had before, but with
its lifetime extended as though you've just `touch()`'d it.
2. You get back a new Session object but with the same uid as the one
you had before with a life time of `sessionTimeout` starting at the
point of the `getSession` call.
3. You get back a new Session object with a different uid - basically
a whole new session, as if the previous one never existed.
Check the PR for the reason why you want Option 2 or 3.
Right now, we are on course of implementing Option 1.
If you think that Option 1 is wrong, please leave your feedback over the PR :)
On behalf of Twisted Matrix Laboratories, I am honoured to announce the release of Twisted 17.9.0!
The highlights of this release are:
- More Python 3 porting, including twisted.mail.imap4, twisted.python.shortcut, twisted.python.rebuild, twisted.web.sux, twisted.web.microdom, and a ton of bugs and inconsistencies fixed.
- twistd on Python 3 now supports the dns, inetd, portforward, procmon, socks, and words plugins.
- HTTP/1.1 and HTTP/2 OPTIONS * request support in Twisted Web
- twist web now accepts the argument --add-header, which can be used to set things like HSTS headers without custom code
- Improvements to IMAP4 behaviour and several logic bugfixes
- Removal of outdated documentation and updates to make them work on Python 3
- Over 70 closed tickets overall.
For more information, check the NEWS file (link provided below).
You can find the downloads at <https://pypi.python.org/pypi/Twisted <https://pypi.python.org/pypi/Twisted>> (or alternatively <http://twistedmatrix.com/trac/wiki/Downloads <http://twistedmatrix.com/trac/wiki/Downloads>>). The NEWS file is also available at <https://github.com/twisted/twisted/blob/twisted-17.9.0/NEWS.rst <https://github.com/twisted/twisted/blob/twisted-17.9.0/NEWS.rst>>.
Many thanks to everyone who had a part in this release - the supporters of the Twisted Software Foundation, the developers who contributed code as well as documentation, and all the people building great things with Twisted!
Amber Brown (HawkOwl)