Ah nice, thanks @tikr and @Agrendalath for these details on the Update Python requirements PRs. I’ll update SE-6622 with this information, and I guess we can treat them in the same manner as the dependabot/renovate PRs.
I think this too can be under the umbrella of SE-6622, as it’s also part of recurring dependency updates. So you can log time to that ticket, and ping FFs for review. (cc @tikr does this seem fine?)
Regarding this PR in particular, what was your motivation for opening it? I ask to try to determine if we do indeed want to keep the common branch in sync with upstream, and maybe we should keep the automation (see discussion above where we removed this automation). Or maybe it’s an infrequent thing when client’s request something?
@tikr@Agrendalath@maxim I updated the description of SE-6622 to be clearer and to include all recurring dependency update tasks (manual or otherwise). Please take a look and let me know if any changes are required.
If we’re happy with this, then we should be mostly covered. I think the only outstanding questions for me now are:
What kind of budget do we want to put towards dependency updates? (I guess this depends on which repo, because some would depend on client budgets.)
Should we have some kind of process or epic to move our maintained repositories toward using Renovate/Dependabot PRs and/or a regular process in the meantime to manually upgrade dependencies?
It wasn’t a client request - I got a notification about the new release/ulmo.3 tag and was curious about the current state of our branch. We’re starting to use this branch for some instances, but we haven’t backported the upstream security patches yet. That was my only motivation here.
My favorite part of this automation is that I can formally merge such changes right away, without pinging people and waiting for a +1. Since running it is basically free (I’m only talking about running an existing GH action, not about merging the PRs), I’m not sure if there are any advantages to removing it. If we’re concerned about duplicated sync PRs, we could add a script that closes an old PR when a new one appears. That said, I don’t have any strong preference here - it’s just a nice thing to have.
Are there any use cases where it would be really worth the extra effort for the existing repos? Ensuring that all new repos contain automatic dependency updates could be sufficient.
Yep definitely - I believe it’s worth it for any repository that we want to maintain. I ran into this for Sprintcraft recently, where we wanted just a small change, but it turned into a larger task because we needed to fix the CI. We could patch the CI by pinning to an old release of setuptools, but none of this would have been a problem if we periodically kept the dependencies up to date. But at this point, it’s a very large task to get everything up to date because we’re talking major version upgrades with breaking changes…
Keeping dependencies up to date should be a standard part of maintaining software. And automated bot PRs serve as a nice reminder, otherwise it’s easy to forget.
Which brings us back around to the openedx release branch syncing automation:
Agreed. If we do want to keep these branches in sync, and there’s interest in reviewing and testing the changes, perhaps we should keep it.
The main advantage of removing it was reducing noise where we weren’t using it. But it seems like we might want to use it? Maybe we need to formally define how we want to manage our common branches, so we have a shared understanding, because there are a couple of approaches now. cc @Agrendalath@tikr@maxim
(cc @tikr does this seem fine?)