Hey everybody, we've recently deployed the changes needed to enable automatic RPM release numbers and changelogs to Koji in staging, and now we want you to throw things at it!
Detailed information is below, but the gist is: it looks like this will be real sometime soon. This is the time to ensure we folks working on it over the past weeks haven't left in any glaring errors. We look forward to hearing from you! Cheers, Nils ------- Background---------- In 2020, a prototype of rpmautospec was developed as feature for the Koji build system to relieve Fedora contributors from manually maintaining the release field and changelog of RPM packages. The results were presented at Nest in August and were met with a positive response. FESCo accepted this feature to be implemented with changes to the underlying release enumeration logic for the Fedora 35 release, and subsequently a CPE team resumed work on the project in April 2021 to bring the revised proposal to fruition. After about 6 weeks of development, the team are pleased to announce that a first version of rpmautospec based on the new logic is ready to be tested in staging. Changed requirements in comparison to the prototype-------------------- ------------------------------- FESCO asked the team to implement a simplified release enumeration algorithm. It basically just considers the number of commits since the last time the version was changed and avoids storing information about historical builds in git tags. What it does at this stage of development ----------------------------------------- * When building packages in Koji/staging, the release field and changelog are maintained automatically from the commits and their log entries (more specifically, their subject lines) in the git repository. The contents of a changelog file, if present in the repository, will override any older commit log information, to allow correcting/amending changelog entries after the fact. * For the release field, flags for pre-release versions, snapshot/extra version information and release number offset exist and are honoured. This isn’t yet implemented for changelog entries, though, i.e. generated changelog entries will have the plain release number in their header even for pre-release or snapshot versions. * The new git history traversal code follows forks in order to support merging branches. For changelog generation, this means it follows a parent with the same tree to support git merge -s ours. Unresolvable merges (with content from disparate branches) won’t fail a build, but this problem will be flagged in the changelog (as the oldest entry). * An API function is provided allowing 3rd party users like fedpkg, rpmdev-bumpspec to check if rpmautospec features are used and adapt to it where necessary. Pull requests to use this have been submitted to rpmdev-bumpspec and fedpkg/rpkg. What’s yet to come ------------------ * Reflect flags to %autorelease in generated changelog entries. * Have `fedpkg local`, `fedpkg mockbuild` (possibly `fedpkg srpm`) support rpmautospec features, i.e. prepare the SRPM on the fly as Koji would do it before building. * Allow for uncommitted changes in local builds with fedpkg, i.e. bump the release number by one and generate a boilerplate “- uncommitted changes” RPM changelog entry. * Up-to-date and more complete documentation (real soon now). Testing Information ------------------- * Source code can be found here: https://pagure.io/fedora- infra/rpmautospec * Installable packages are available for all supported Fedora versions, from 33 onwards. * Quick Start: - The staging environment is separate from what you use day to day, recent changes to your account might not have made it there. Ensure you can log into your Fedora account on staging, and that it is part of the necessary groups (e.g. packager): https://accounts.stg.fedoraproject.org If you have issues with your staging account, please log a ticket with Fedora Infrastructure here: https://pagure.io/fedora- infrastructure/new_issue - Clone the staging repository of a package: `fedpkg-stage clone ...` - Move the existing changelog entries beneath %changelog in the spec file into a file named changelog in that same directory and add that file to be tracked by git. - Enable automatic release number enumeration and changelog generation in the spec file: ... Release: %autorelease ... %changelog %autochangelog - Commit these changes to git, push and build: git commit -m "Use automatic release and changelog" git push fedpkg-stage build - If you want to use the Koji CLI tool, point it at staging this way: koji --profile=stg ... * We are interested in issues concerning using rpmautospec, if you need help but also where its behavior is unexpected or even disruptive, such as: - (How) Can I do …? - My package doesn’t build if I use automatic release and/or changelog. - The automatically generated changelog of my package looks weird. - The documented way to do … doesn’t work. - I don’t use rpmautospec features, but it still touches my package. * If you have questions, contact us on IRC, the people on the team hang around e.g. in the #fedora-apps channel (among others) on irc.libera.chat. * Please file bugs here: https://pagure.io/fedora- infra/rpmautospec/new_issue Mind that time is scarce and therefore we have to triage/prioritize, i.e. not all bugs/issues may be addressed before we deploy to production. * For a quick turnaround, we will redeploy changes/fixes to the builders in staging without prior notice at any time, this can affect unfinished test builds at the time. Production-Ready Plans ---------------------- The team are on track to deploy the project to production by end of June 2021. We will coordinate the deployment in production with the people from the Fedora Infra & Release Engineering teams and announce it with more precise dates separately. Feature ideas for future development------------------------------------ These items are out of scope for the initiative but we would like to have them at some point. We might get around to some of these if time permits, but no promises. * Convenience tooling like “convert spec file to using automatic release and changelog”, “freeze generated changelog to file for editing”, “show me the NVR of the next build”, etc. * “Magic comments” to e.g. skip commit logs for the changelog. * Longer changelog messages than just the commit log subject. Links ----- * Project Repository: https://pagure.io/fedora-infra/rpmautospec * Nest Slides (Prototype): https://nphilipp.fedorapeople.org/nest2020-rpmautospec-slides/ -- Nils Philippsen "Those who would give up Essential Liberty to Software Engineer purchase a little Temporary Safety, deserve neither Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: D0C1 1576 CDA6 5B6E BBAE 95B2 7D53 7FCA E9F6 395D _______________________________________________ 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
