Update git branch to "main" across Pylons repos.

[jvanasco]

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:

• pylons/pyramid
• pylons/pyramid-cookiecutter-starter
• pylons/pyramid_debugtoolbar
• pylons/pyramid_tm

[mmerickel]

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?

[jvanasco]

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?

• https://pylonsproject.org/community-coding-style-standards.html
  • Add a section "Git Branches" that
    • requests "New Projects" to use the title "main"
    • acknowledge a desire to migrate all repos to "main", however the workload is quite large considering there are over 100+ repos.

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.

[stevepiercy]

I support this effort, and already did so on Deform and Deform Demo.

• https://github.com/Pylons/deform
• https://github.com/Pylons/deformdemo

RTD was trivial, after the switch, just select main instead of master.

We also have trypyramid.com content that would need to be updated.

[mmerickel]

@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.

[jvanasco]

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.

[jvanasco]

Good news! Cookiecutter renamed "master" to "main" earlier this year. In this ticket/comment, the following is noted:

I rechecked how git works with such rename issues right now. It automatically redirects blob links isuues etc, so it is not a big problem.

There should be no issue. Of course, I will do a test before submitting a PR.

[jvanasco]

I've generated PRs for the following packages, which I assumed to be the more
used options:

• pyramid-cookiecutter-starter
• pyramid
• pyramid_debugtoolbar
• pyramid_mako
• pyramid_tm
• pyramid_mailer

I believe the two options to handle the branch rename are:

• copy "master" to "main", set that as default, merge this PR.

or

• merge this PR to "master", then rename to "main" and set that as default.

A few notes:

• some tests seem to fail on all/many of these. this looks to be limited to
  docs building and black, apparently due to version pinning or the lack thereof.
  i'm not sure how to handle those. please advise.
• pyramid_mailer is not plugged into github actions and is no longer connected
  to Travis, although it references Travis

I did not touch the following core packages, which I think are more
actively maintained, and I did not want to step on any toes. I'd be happy to
generate PRs for them if needed.

• deform
• hupper
• waitress
• webob
• webtest

I could be wrong about this, but I don't recall seeing the other repos come up
as much on the lists for problem solving, usage recommendations, or development
cycles so I'm considering them legacy.

[mmerickel]

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.

[jvanasco]

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.

[mmerickel]

That’s excellent thank you.

[stevepiercy]

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.

[digitalresistor]

• 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.

[jvanasco]

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.

[jvanasco]

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.

[mmerickel]

We moved a few packages successfully but several are going to need other repo CI updates before we can merge changes.

[jvanasco]

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 -latest version. e.g.:

https://github.com/Pylons/pyramid_debugtoolbar/blob/master/.github/workflows/ci-tests.yml#LL27

ubuntu-latest was recently upgraded to 22.04 (from 20.04). Python2 is not built into that image and there are no plans to do so. I assume the other platforms may be similar already, but have not researched this. A test runner matrix should be able to resume support and pass CI tests by replacing the ubuntu-latest label with ubuntu-20.04.

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.

[mmerickel]

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.

[jvanasco]

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.

[mmerickel]

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-debugtoolbar
• pyramid-mako
• colander
• webtest (need to ping @gawel to see if there are any reservations about it, or I'm happy to help)

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.

[mmerickel]

Closing this issue given my comments above. We are sufficiently close to done with this to stop tracking it.

[gawel]

Hi! @jvanasco already provided a branch to rename master in webtest. I've just merged it and renamed the branch to main. Seems ok

[mmerickel]

Awesome thank you @gawel!

[jvanasco]

thanks so much, everyone!