Mailman 3 October 2017 - Twisted

[Twisted-Python] Weekly Bug Summary
by trac＠twistedmatrix.com Oct. 14, 2017

Oct. 14, 2017

1 0

[Twisted-Python] HTTPS reverse proxy using twistd, twist, or twisted.web?
by Craig Rodrigues Oct. 10, 2017

Oct. 10, 2017

Hi, Can someone give me a short snippet for how to set up a HTTPS reverse proxy using twistd, twist, or twisted.web ? I'd like to add an example of this to the documentation examples, since it is a pretty common thing to do these days. -- Craig

3 3

[Twisted-Python] Weekly Bug Summary
by trac＠twistedmatrix.com Oct. 7, 2017

Oct. 7, 2017

1 0

[Twisted-Python] Defining the review workflow on top of GitHub PR
by Adi Roiban Oct. 6, 2017

Oct. 6, 2017

I am restarting this discussion https://twistedmatrix.com/pipermail/twisted-python/2016-May/030333.html 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 subject. 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 rejected :) > 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. ---------- Thanks! PS: I have checked pyca/crypography but I don't see any pattern there and a lot of PR are merged without any comment https://github.com/pyca/cryptography/pulls?q=is%3Apr+is%3Aclosed -- Adi Roiban

3 6

[Twisted-Python] Required tests for a PR to be merged
by Adi Roiban Oct. 2, 2017

Oct. 2, 2017

Hi, 1. Are Travis OSX builds functional yet? Can we switch to Travis for OSX builder? Over https://www.traviscistatus.com/ I see no backlog for macOS. ------------ 2. Right now, when we receive a PR from a non-team member, I think that the only way to trigger the required tests is to create a new branch in twisted/twisted. Then you can go to https://buildbot.twistedmatrix.com/boxes-supported?branch=9176-inlinetraceb… and force the tests. This looks complicated, so what I was doing, is create a new PR. -------- Am I doing something wrong? Is there a simple way? Am I the only one who thinks this is not productive? -------- What I am thinking is to have a single PR (the once created by the author). Once a Twisted team member has reviewed/checked the PR, a message like "Go, Buildbot, go!" can be left as a comment and the Buildbot GH hook will trigger the stable tests for that branch. In this way, buildbot runs are only triggered for external branches after a core team member has checked the code and assure that no malware is contained. With GitHub we can do changs to any forked repos... so if small changes are required, Twisted team members can push directly to the external forks... not sure if this is a feature or a security bug :) --------- What do you think? Do you see any problem in this? Will such a change make life easier for you? I should be able to update the current GH Buildbot hook to handle the proposed change. -- Adi Roiban

3 5

[Twisted-Python] Migrating Trac Tickets to GitHub issues
by Adi Roiban Oct. 1, 2017

Oct. 1, 2017

Hi, 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 migration? 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 attributes. 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 GitHub data. ---------------- 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. Thanks, 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 changes. -- Adi Roiban

4 7

[Twisted-Python] Weekly Bug Summary
by trac＠twistedmatrix.com Sept. 30, 2017

Sept. 30, 2017

1 0