-
Notifications
You must be signed in to change notification settings - Fork 879
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update git branch to "main" across Pylons repos. #3712
Comments
It's an effort issue as you noted. If you can coordinate the changes across all of the docs and references I'm willing to click the buttons to merge them and to modify the setting in the github repo. Also need to evaluate how the change will impact RTD. Finally I have no clue how cookiecutter works now? It used to default to master? |
Thanks, awesome! I'll look into cookiecutter. If it looks fragile/unsupported, I won't touch it. What are your feelings on a PR to the pylonsproject.org site covering the following?
There have been a handful of open source projects which have vehemently opposed D&I efforts like this for various reasons - which are usually due to simply not understanding how they are problematic. In my experience, a simple statement along the lines of "We understand this is an issue, We'd like to fix it, You are welcome here" goes a long way to differentiate a project. |
I support this effort, and already did so on Deform and Deform Demo. RTD was trivial, after the switch, just select main instead of master. We also have trypyramid.com content that would need to be updated. |
@jvanasco I’m not going to promise switching every repo as quite a few are inactive now but new repos and active ones are fine to include. We’re fully supportive of the effort. |
Of course. That's why I said a "desire". We switch the active/popular ones (a tiny amount) and just give a general message supporting D&I that acknowledges there is an issue with the legacy names. |
Good news! Cookiecutter renamed "master" to "main" earlier this year. In this ticket/comment, the following is noted:
There should be no issue. Of course, I will do a test before submitting a PR. |
I've generated PRs for the following packages, which I assumed to be the more
I believe the two options to handle the branch rename are:
or
A few notes:
I did not touch the following core packages, which I think are more
I could be wrong about this, but I don't recall seeing the other repos come up |
pyramid-jinja2, pyramid-retry, and pyramid-exclog should be in the list. As far as actually rolling this out I can probably try to find some time to test it with the debugtoolbar and then we'll need to go from there to see how long it's going to take to do for more projects. Projects that are not up to date with their project config (github actions) are going to be a pain and will need to be modernized before making other changes... at least that is my current thinking. |
Ok. I can do those too, and I'll put together a wiki page that lists the status of the migration and project config modernization with links to relevant tickets. That should make oversight on all this easier. |
That’s excellent thank you. |
https://pylonsproject.org/projects.html has a list of "core" projects that we maintain. https://trypyramid.com/extending-pyramid.html can be filtered by "Pylons Project", which includes Pyramid add-ons that we maintain. |
I'd accept PR's for all of those. |
I’m happy to generate PRs for those and integrate them onto the wiki thing I’m doing. I’m pretty com with the workflow and search for this stuff.
After a bit more testing and research, the workflow on the maintainer side will require a branch rename. The PR merge can happen before or after, but the workflow cannot be creating a new “main” branch from the PR. GitHub has some optimizations/features that will redirect legacy links to “master” onto “main” that should eliminate any concerns with backwards compatibility for users who have CI/build systems that hit GitHub— but that is only available via branch rename.
… On Nov 15, 2022, at 12:01 AM, Bert JW Regeer ***@***.***> wrote:
deform
hupper
waitress
webob
webtest
I'd accept PR's for all of those. webtest is the only one that is on that list that is not maintained directly by myself or @mmerickel.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.
|
I've audited all the above named packages. The results are on the following wiki page: https://github.com/Pylons/pyramid/wiki/2022-Fall-Package-Audit I will update the wiki as I develop PRs. |
We moved a few packages successfully but several are going to need other repo CI updates before we can merge changes. |
For any repos that are failing CI on Py27 no longer being supported, example pyramid_debugtoolbar, the issue is with the CI running using the https://github.com/Pylons/pyramid_debugtoolbar/blob/master/.github/workflows/ci-tests.yml#LL27
I am not sure if a single action file can support ubuntu-20.04 for python2.7 and run everything else on ubuntu-latest. I know that is possible with multiple action files. |
My goal would be to drop py27 as part of updating the CI. For pyramid it may be worth pinning, but not for the addons. |
Absolutely agree with that goal. I wanted to share in case a critical/security patch needs to be updated on any project before Python2.7 is dropped and/or the CI gets the full overhaul. |
Alright, we've made a lot of progress. As an update pyramid is now converted as well as most of the other main repos. The ones remaining that I have taken note of are:
pyramid-chameleon also needs help but I stay out of that one personally and don't know who will step up to do it. pyramid-mailer is also remaining but that one is a can of worms, we really need a maintainer for that library and repoze.sendmail. I'm afraid to edit it myself cuz I just don't know the specs very well. |
Closing this issue given my comments above. We are sufficiently close to done with this to stop tracking it. |
Hi! @jvanasco already provided a branch to rename master in webtest. I've just merged it and renamed the branch to main. Seems ok |
Awesome thank you @gawel! |
thanks so much, everyone! |
I was working on releasing a cookiecutter template and noticed both https://github.com/Pylons/pyramid-cookiecutter-starter and https://github.com/Pylons/pyramid use the legacy term
master
as a branch name and not the current standard (adhered to by Python, Github, and numerous organizations) which is sensitive to the needs of Diversity and Inclusion efforts.From personal experience, I understand the complexities of changing the branch name as it requires updates to documentation/code and affects testing/CI systems. A few years ago I migrated 30+ repos I control, and assisted a handful of open source projects do this as well. That being said, I'd really love to see the various Pylons projects migrate to the new standard. It's a bit hard for me to advocate/document something using the legacy terminology.
104 repositories is a lot and I know resources are small. This will take time. However, I am willing to generate a first PR for the following projects immediately as I need to document them in something and I would prefer to not use the outdated term:
The text was updated successfully, but these errors were encountered: