search

pypa / twine

Utilities for interacting with PyPI
https://twine.readthedocs.io/
Apache License 2.0
1.62k stars 309 forks source link

Maintenance updates #1181

Closed jaraco closed 1 day ago

jaraco commented 2 days ago

As reported in https://github.com/pypa/twine/pull/1123#issuecomment-2508178414, Ian is taking a break from OSS projects and Brian has been inactive on this project for a while. As a result, I'm taking over sole ownership of the project. I'll be disabling some of the two-person controls for the project as well as removing inactive admins (without prejudice, meaning they can request restoration).

jaraco commented 2 days ago

@bhrutledge, do you still consider yourself active on this project? Happy to keep you on as a backup admin if so.

jaraco commented 2 days ago

I'm removing the protection of required pull request approvals in order to move my own pull requests forward:

image

woodruffw commented 2 days ago

FWIW: if you want/need another maintainer (or triager), I'm happy to be one in the short term -- I know the twine codebase decently well at this point, with the contributions I've made around PyPI security/API changes over the years.

(I have a mild preference for not being a maintainer in the long term, since I've already got enough stuff 🙁 -- but I'm happy to be the second person for two-person control purposes.)

sigmavirus24 commented 2 days ago

I'm not inactive I'm just not able to spend lots of time and after certain past interactions have Jason muted. I'm not doing a lot of open source but I still work on things when I have time. And after breakages arbitrarily merged by folks who are not maintainers here but have elevated org privileges, I explicitly enabled requiring pull request approvals before merging

jaraco commented 2 days ago

FWIW: if you want/need another maintainer (or triager), I'm happy to be one in the short term -- I know the twine codebase decently well at this point, with the contributions I've made around PyPI security/API changes over the years.

Awesome! I'm grateful for the support. In my opinion, anyone willing to contribute > 0 to a project is welcome. I've added you as a maintainer.

woodruffw commented 2 days ago

I sent a message to Ian as well over Mastodon, but to copy the substance of it here: I wasn't aware that there was a maintenance dispute here, and I'm not super comfortable being an active maintainer/change mediator until @sigmavirus24 OKs it (since he's been very gracious with reviewing my work, and I don't want to step on his toes).

I'm very sorry for any confusion/tumult I caused here @jaraco -- I shouldn't have responded so carelessly. Please feel free to remove my maintenance bit if you'd prefer.

sigmavirus24 commented 2 days ago

I'm very comfortable with @woodruffw being a maintainer. I'm not comfortable with removing the requirement for a pull request to be reviewed first as this requirement would have prevented main from being broken in the past when folks have self-merged without review despite CI failing the PR.

satmandu commented 2 days ago

Thanks all for working through this. As a maintainer for Chromebrew I entirely concur with requiring pull requests to pass all necessary unit tests and have a review by someone who didn't submit the PR. Such a process has saved us from countless headaches in the last several years.

I setup an active team for our organization with everyone who seems to be substantially responsive to review requests. I now add that to all PRs I generate.

Having said that, we have also encountered periods when a reviewer was not available for urgently needed PRs, I would also suggest that such second-person checks might be considered best effort for a volunteer-run project but not mandatory where there is a paucity of reviewers.

Maybe it would be useful to have a mechanism where the required review (or review re-request) times out after some number of days (assuming some number of reminder prompts to reviewers).

Waiting many weeks for reviews on PRs to address issues in a project affecting many other software projects might be considered problematic.

sigmavirus24 commented 2 days ago

For projects that secure people's interactions with something like PyPI, security must be the top priority. That means no relaxing of requirements

satmandu commented 1 day ago

For projects that secure people's interactions with something like PyPI, security must be the top priority. That means no relaxing of requirements

As a normative argument I completely agree.

However that becomes extremely theoretical if there aren't enough people available to review requests, and abandoned projects with unreviewed and unmerged PRs for security issues are all over GitHub.

I don't have good solutions for a community run unfunded project. Maybe some of the people using the software in a for-profit capacity would be able to chip in with bounties or whatever to provide incentives for quick reviews.

But thank you for the quick set of reviews and merges today. I'm looking forward to having 6.0.0 tagged so I can pull it down from PyPi so I can build some tagged releases.

woodruffw commented 1 day ago

Just to close the loop: I'm now acting as one of the maintainers; @jaraco or another admin will need to to re-enable PR approvals and other merge rules since I don't have sufficient permissions to do it on my own 🙂

jaraco commented 1 day ago

I've restored the "requiring approvals" for pull requests, so no changes have been made other than to add woodruffw.

certain past interactions have Jason muted

I'm not sure what it means to be a co-maintainer on a project where my interactions are systematically ignored. I'm not even aware of what issues Ian has or how I could address them. I welcome Ian to spark up a conversation or file an issue, but given the current position of enforced ignorance, I'm going to act as if Ian isn't part of the active maintenance and no longer rely on his actions to get work done.