Re: Keeping track of inconsistent backports
Hi, I have a similar problem (but on a much smaller scale): The certbot stack comprises ~ a dozen packages which should be updated in lockstep. We push the same version to all supported Fedora releases + EPEL (mostly). To do that somewhat efficiently I built/extended some scripts: https://github.com/FelixSchwarz/fedpkgscripts Basically these handle issues like: - merge a branch to N other branches - push git changes in N branches - build branch X for N packages (either in mock, in COPR or with koji) - check for unpushed/uncommitted changes in a repo - pull git changes for N packages - set the new version in a spec file based on bugzilla queries, download the new sources, verify with gpg and run "fedpkg new-sources" if verification is successful + some other stuff I probably just did not remember currently really a lot of "ad hoc" code but I'd be happy to contribute to a common set of tools :-) Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Keeping track of inconsistent backports
On 11/15/21 14:48, Fabio Valentini wrote: I don't really have a solution here, but I'd be interested in looking at this problem. For example, most* [1] packages in the Rust stack will have (and should! have) the same versions across all supported Fedora branches. For any Rust packages that I push updates for, I update them right away across all branches, and that works very well to prevent me from forgetting things. However, any "newcomers" (or contributors who are more easily distracted than me) will often mess that up, making it hard for me (main Rust stack maintainer right now) to keep things aligned when I update other packages. I'm glad to know I am not alone! I started down a path of writing a script that does something like this: 1) Scrape pagure's API to get all of my RPM repositories 2) Request the bodhi update versions for the package 3) Remove the ".fc##" from the version numbers 4) Examine the latest available versions for each release and highlight differences Step #1 takes 1 API request per 100 packages (which is 3 API requests for me), but #2 requires one API request per package. I feel like someone's going to be upset with me eventually for running so many API calls. I thought Koschei might be able to help with this but I couldn't figure out a way to get that information from there. -- Major Hayden OpenPGP_0x737051E0C1011FB1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Keeping track of inconsistent backports
On Mon, Nov 15, 2021 at 8:42 PM Major Hayden wrote: > > Hey there, > > As much as I try not to, I sometimes forget to backport a package that I > manage. > > For example, Google's Python SDK updates rather frequently and I usually > bring those changes into rawhide fairly quickly. The SDK is made up of > plenty of different packages that release at different times. Mondays > are usually the day when I take all of the most recent updates, test > them out together, and backport the updates to the most recent stable > version. > > However, I sometimes miss one or two of these packages. It's usually not > a big deal since I might process another update for that package within > a week or two. I'd like to get better with this and somehow identify > which package updates made it into rawhide without getting backported. > > Do we have any tools to help with this now? I was looking at potentially > writing my own scripts to do this but it would involve a *lot* of calls > to mdapi and that's probably not the most infrastructure-friendly > option. My goal is to look across my packages and find the ones with a > version mismatch from rawhide to stable. > > Thanks for reading this far and for any ideas you might have. 珞 I don't really have a solution here, but I'd be interested in looking at this problem. For example, most* [1] packages in the Rust stack will have (and should! have) the same versions across all supported Fedora branches. For any Rust packages that I push updates for, I update them right away across all branches, and that works very well to prevent me from forgetting things. However, any "newcomers" (or contributors who are more easily distracted than me) will often mess that up, making it hard for me (main Rust stack maintainer right now) to keep things aligned when I update other packages. [1]: some package sets contain non-self-contained breaking changes, for example the latest gtk-rs bindings are only available on Fedora 35+ Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
