Should blurb and cherry_picker move to their own repos?

[Mariatta]

When we started with blurb and cherry-picker, they were simply command line tools and not published to PyPI.

Now blurb and cherry-picker are in PyPI independently, each have their own chaneglog, their own License (blurb is BSD, cherry-picker is Apache), their own readme, their own owners; perhaps they should be split into their own repos?

One inconvenience I encountered while both are under the same repo, is https://github.com/python/core-workflow/issues/313. I wanted to move cherry-picker's documentation to readthedocs, but readthedocs support one documentation per repo.

I'm also wondering how having two packages in the same repo affect GitHub's dependency graph 🤔 Perhaps there is no real dependency other than blurb-it depends on blurb, and miss-islington depends on cherry-picker.

[asvetlov]

I think the separation makes sense.

[brettcannon]

Honestly, I think we should split the projects out and then shut down the repo. This was partially an experiment to see if it would work out better than core-workflow@ and I don't it provides much at this point beyond a place for cherry-picker and blurb. 😄

[Mariatta]

Ok, I can look into moving cherry-picker out. Don't know about shutting down repo. I've been telling people to file general workflow-related issues here, the ones not specific to bots. Just need a different place for that purpose..

[brettcannon]

@Mariatta I would say issues should potentially be brought up on discuss.python.org, but we can worry about what to do after cherry-picker and blurb move.

@larryhastings FYI

[Mariatta]

I've created a project board for things need doing: https://github.com/python/core-workflow/projects/2

[Mariatta]

@larryhastings Can I go ahead and move blurb out? Or you want to do this yourself?

[Mariatta]

While I prefer using discourse for discussions over mailing lists, sometimes we need issues to reflect tasks/bugs where we can assign people, and close when the task is done. Discourse doesn't seem to be a natural place for this.

I can't even close my own Discourse post, an admin needs to do it.

So I think this repo is still needed for core-workflow "issues" 🤔

[hugovk]

I agree we should move blurb to its own repo, and keep this one for issues.

Shall we do this before setting up automated deploys for blurb in this repo? python/blurb#4

[Mariatta]

Yes I would suggest moving it out first so we don't need to repeat the process later on.

[hugovk]

I've made a blurb repo on my account: https://github.com/hugovk/blurb

I followed the instructions at https://help.github.com/en/articles/splitting-a-subfolder-out-into-a-new-repository (from the project https://github.com/python/core-workflow/projects/2) to filter the blurb directory preserving history.

For the test files (.github/, .pre-commit-config.yaml etc) I just copied those over, I don't think the history on those is so important. And then updated file structure for the new repo.

Next steps:

• Follow the org repo policy:
  • open a discussion to seek consensus in the Committers Discourse category: https://discuss.python.org/t/create-dedicated-blurb-repo/49048
  • once people are satisfied with that, ask the Python steering council to grant permission: python/steering-council#240
  • transfer repo

[CAM-Gerlach]

This is great to see, thanks @hugovk ! Been wanting to help see this happen for a long time.

Might be nice if we could ask @larryhastings if we could remove the first and last two lines of the LICENSE.txt file that aren't actually part of the BSD-3 license itself (the blurb version, the seemingly redundant mention of it being under the blurb package, and the ancillary mention of the PSF contributor agreement) so the license gets properly detected as an OSI-approved open source / FSF-approved free software license.

Alternatively, we could relicense it as Apache-2.0, as Cherry-Picker was and as the PSF contributor agreement (explicitly mentioned in the current license) gives the right to (and thus the current license text explicitly allows, though it is also permitted by the terms of BSD-3 so long as the original license text is retained in e.g. NOTICE.txt).

Also could be something to ping the new legal counsel on.

[hugovk]

Update: after a positive response on Discourse, I've asked the steering council for permission to transfer: python/steering-council#240.

[hugovk]

Update: The SC approves, I've moved the repo to https://github.com/python/blurb and opened #533 and python/devguide#1302.

Next steps:

• Add integrations:
  • Dependabot
  • CLA bot
  • https://pre-commit.ci/
• Grant access:
  • Core team
  • Anyone else?
• Move issues
• Notify people

[hugovk]

Please could @python/organization-owners add Dependabot, CLA bot and https://pre-commit.ci/ to https://github.com/python/blurb?

Also double check the core team has merge access like in other similar repos (for example, this one and https://github.com/python/cherry-picker).

[ambv]

On it.

[ambv]

Dependabot enabled.
CLA bot enabled.
pre-commit.ci enabled.
python/core team members added as writers.

[![pre-commit.ci status](https://results.pre-commit.ci/badge/github/python/blurb/main.svg)](https://results.pre-commit.ci/latest/github/python/blurb/main)
``

[hugovk]

@ambv Thank you!

---

@Mariatta Thank you for the project: https://github.com/python/core-workflow/projects/2?query=is%3Aopen+sort%3Aupdated-desc It was very helpful doing the transfer 👍

---

We're almost done here. Remaining:

• Remove blurb code from repo and point to python/blurb #533
• Notify people

The (five-year-old) project card listed:

Notify:

• core workflow mailing list
• core workflow discourse
• python-committers
• python-dev?

In 2024, I think we only need:

• Notify via Discourse core development

[hugovk]

[x] Notify via Discourse core development

Done: https://discuss.python.org/t/blurb-now-lives-at-python-blurb/50239

I think that's everything, thanks all!

✨🏡 https://github.com/python/blurb ✨