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
This is the first time we’re working on a process for tackling dependency updates systematically, so it’s difficult to say how much time we’d need to be able to do it consistently and well.
Could we start small and see where it gets us? For example, something like 1-2h/sprint for internal repos might be a good starting point. It should be doable from a budget perspective – even in cases where Serenity uses up its full monthly budget for non-billable work on other tasks, 2-4h of additional time logged would be manageable in terms of sustainability impact. (The cell would likely still be able to stay on budget for the year as a whole.) If more/less time is needed, we should find out along the way.
For client-specific repos, I don’t think we can set/mandate a specific recurring budget. It seems like it should be up to individual client owners to decide if and when to spend time following up on dependency PRs against relevant repos.
Just to clarify, when you say “maintained repositories”, which set of repos are are you thinking of exactly? Repos that we own/created vs. all repos in OpenCraft’s GitHub and Gitlab organizations (including forks) vs. something else?
Either way, between the two options that you mentioned it seems like moving towards using Renovate/Dependabot would probably be the way to go. Even for a smaller set of repos (e.g. one that excludes forks), we probably wouldn’t have the bandwidth or the necessary budget to manually upgrade dependencies on a regular basis in the medium or long term.
We already did the work for removing the automation that creates sync PRs. So if the main reason for keeping the sync PRs is that they’re a nice thing to have (but not something we really depend on or want to deal with on a regular basis), I’d lean towards sticking with the earlier decision to disable them for now.
If not having them does create problems down the road, we can always bring them back. And if someone wants to sync branches manually, like you did with open-craft:openedx-platform#840@Agrendalath, we now have a clear process for doing that (via SE-6622).
But for the coming weeks it might make sense to focus on getting into a good rhythm with the new approach for handling dependency updates, and refining that if necessary.
By “a couple of approaches” do you mean using automated vs. manual sync PRs?
Sounds good. I updated the ticket to reflect this.
I was thinking of all repositories that we’re using in production somewhere - so this would be pretty much all repositories in our Github and Gitlab orgs, except for:
archived repositories (we archived a lot in BB-10596, so the set of unarchived repos has less noise now)
forks that we’re only using for proposing PRs from
repos for testing/demos/PoCs
Yeah exactly, it gets unmanageable pretty quick
Agreed. Let’s leave that automated branch sync workflow disabled for now. We can always bring it back.
Ah yes sorry - I mean:
automated sync PRs
regular manual sync PRs
no sync PRs (ad-hoc apply patches or sync when a client requests it)
Do you think you could list out the repos that match these criteria so we’d get an idea of the total amount of work involved?
That would probably help with making a decision as to whether it would make sense to create a dedicated epic for the work.
Re: sync PRs / common branches
No worries.
The decision to disable sync PRs means that we’ll be doing #3 for now, I guess
Let’s see how it goes – if we find that some sort of regular syncing is in fact necessary, we can revisit this conversation. (I agree that in that case it would make sense to formalize the process a bit more than it used to be, and to properly document whatever approach we’d settle on.)
There are about 120 repos on that spreadsheet. There will probably be more repos on that list that can go, but still it would be a rather large undertaking.
@samuel Thanks for putting that together. Based on a quick glance it does seem like we could prune that list some more. (Good news! )
It might also make sense to sort/partition it based on relevant criteria (client vs. internal, infrastructure vs. xblock/plugin, belongs to active project vs. not, etc.)
If you have a couple hours to spare from your Community Liaison budget for Q1-Q2, maybe you could create a ticket for completing these steps?
By the end of it we should have a better understanding of how client and internal budgets would be impacted if we were to launch an initiative to move OpenCraft’s maintained repos toward using Renovate/Dependabot PRs (and regularly review/merge them afterwards).
@samuel To be able to take this work/project into account for non-billable budgets for Q3-Q4, it would be good to get more details sooner than last sprint of June
If you’re worried about ending up with too few hours left for BB-10597: Community Liaison for the rest of the quarter, I just checked – it should be OK to use a few hours on the ticket you’ll create without touching the Q1-Q2 budget for BB-10597.
(cc @tikr does this seem fine?)
