On Mon, 28 Dec 2020 at 01:00, Jean-Paul Calderone <exarkun@twistedmatrix.com> wrote:
On Sun, Dec 27, 2020 at 6:59 PM Adi Roiban <adi@roiban.ro> wrote:
Hi Craig,
On Sun, 27 Dec 2020 at 20:10, Craig Rodrigues <rodrigc@crodrigues.org> wrote:
On Sat, Dec 26, 2020 at 3:50 PM Adi Roiban <adi@roiban.ro> wrote:
Hi,
I plan to act as a release manager for the next release and follow the plan documented at
https://docs.twistedmatrix.com/en/latest/core/development/policy/release-pro...
I was previously working on releasing Twisted. I was running into various roadblocks, but was moving forward, and got permission from Glyph to move forward with this. Has this changed?
If you want to do the release, I am more than happy to not have to do the release myself :)
Unfortunately, Amber did not respond to any e-mails that I sent to her and Glyph, so I tried to move forward the best that I could.
Is there anything still blocking you ? Can I help?
So no other tickets are in the blocker queue: https://twistedmatrix.com/trac/report/26
------
Do you know any other release blocker issues?
I filed this: https://twistedmatrix.com/trac/ticket/10070
which I found with Pierre Tardy's help by running buildbot's test suite against Twisted trunk. This looks like a problem on the Twisted side, and should be fixed before a Twisted release is pushed out.
OK. I closed https://twistedmatrix.com/trac/ticket/10069 as I think it's a duplicate.
Do you or Pierre plan to fix that ticket?
I think that you should block the release only if someone is committed to fixing the release blocker.
I plan to update the release documentation to make it clear that all release blocker tichet should have an owner and there are plans to fix the ticket in a maximum of 2 weeks.
Otherwise we risk to block the release forever... and if we delay forever people will start using "trunk" and if everybody is using trunk, what is the point of a release :) ?
Part of the point is that when someone runs `pip install ...` they get a *working* version of Twisted, to the best of the project's ability to provide one.
Fortunately many regressions aren't that difficult to resolve. At worst, find the merge that introduced them and revert it. This works best when regressions are found in a timely manner, of course. Of course it's also nice if the problem can be fixed without backing out whatever (presumably desirable) set of changes it came along with.
Part of the release managers job is to motivate this kind of work to happen. A standing policy to revert the cause of a regression can also serve as good motivation to get the other kind of fix in, too.
It's better if these known regressions don't linger for months, though. It looks like the Buildbot PR had a failing CI run in October. I'd suggest that not waiting until December is a good way to avoid having these kinds of situations turn into a larger problem.
Jean-Paul
Thanks Kyle and Jean-Paul for your feedback. With GitHub Actions is easy to have wheels and full docs published on PyPi and Read The Docs. We can do a release candidate and the release candidate might be a good way to do one more release rehearsal before the final release :) I was wrong to suggest installing based on trunk ... even when use pip to install from git, it should have been installed based on the release branch :) But that issue is solved. ----- I guess there are no comments against removing a ticket from the release-blocking list if the ticket is not active for 1 or 2 weeks. ----- Crag, if you have time, can you join the IRC channel ? Cheers -- Adi Roiban