I'm late to the party, but here we go anyway. Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> writes: > [snip] > > Here is what the vision we came to and that we would like to discuss: > > ○ Every changes to dist-git is done via pull-requests As long as this is not mandatory, sure. > ○ Pull-requests are automatically tested > ○ Every commit to dist-git (ie: PR merged) is automatically built in koji Make that every tag and we are sold. > ○ Every build in koji results automatically in an update in bodhi > ○ Every update in bodhi is automatically tested > ○ If the tests pass, the update is automatically pushed to the repository So no more user's testing being able to test updates manually? I have packages where I'd actually prefer them to be tested manually (i3, i3status, i3lock, sway et al), because I haven't had the time to setup openQA for these yet. > > > For this workflow to work nicely we need to fix a few things first: > > - We need to work on the change logs in the spec files, as otherwise > pull-requests are going to conflict more often than not Let's please just get rid of them and the same for the Release tag (that should be automatically bumped by the build system on each rebuild, as we want automatic rebuilds, don't we?). > - We need to fine a place to insert the end-user information about an update (in > the PR description?) The git tag as Randy & Jeremy suggested. > [snip] > > Do you like this vision? Would you change some pieces of it? Would you change it > entirely? > In an ideal world, what would packaging software look like to you? Like a combination of our current way of doing things combined with openSUSE's Open Build Service (not only the automatic rebuild part, although that is nice too). What imho OBS did right is that it provides a single entry point for packaging: a unified web UI with all the information & build states and a unified CLI client for doing literally everything. You want to update package `foo`? `osc branch devel:FooProj:foo && osc checkout home:MyUserName:branches:devel:FooProj:foo`, make your changes there, commit them and send a submitrequest (something like a pull request). You want to become maintainer of a package? `osc reqmaintainership`. Who maintains `bar`? `osc maintainer bar`. And so on… So what I'd love to see would be the single entry point to packaging that Christopher described, not only as a web application, but also as a CLI client. To be more specific: - My package's spec file is tracked in dist-git or git + git-lsf, depending on a setting I'll either have one branch for all the Fedora & EPEL versions or one branch for each version. - Commits to the repository result in CI run (a default one, like rpmlint + additional custom tests). I can push -f all commits since the last tag, but nothing before that. Once I tag a commit, it is build "for real" (and tested) and automatically submitted as an update to bodhi. The changelog gets generated from the tag message and included into bodhi. On the other hand it must be possible to submit multiple packages as an update. I could imagine something like a `fedpkg update-multiple package1:$commit1 package2:$commit2 -m $message` that would tag the specified commits and push all builds into a single update to bodhi. - the-new-hotness will send pull requests once a package is updated upstream. The pull request gets built & tested as an ordinary commit would. As a packager I have the option to "merge + tag" (also being able to modify the tag), which automatically submits this as an update. This would tremendously simplify the update process for most of my packages. - If I would have a package that requires a lot of patches, then I can be granted the option to use source-git and keep my patches as commits on top of an upstream branch. This should imho require some form of approval though, as this can easily escalate into hundreds of patches. - Package updates cause a rebuild of all dependencies (+ a test run of each of these). Only a successful rebuild is allowed to be submitted to bodhi. - Allow the creation of package "namespaces" or "projects" (stolen from OBS' development projects): a packager or a group can create a namespace on the git forge, into which they can fork/link arbitrary packages from the distribution. The forked packages become a part of the buildroot of this namespace, all others are inherited from the distribution itself and are unaffected by changes in this namespace. This should allow packagers to run experiments which do not affect the distributions build root, but still be able to test the impact of their changes on a larger set of packages. Packagers should then be able to send their changes back via a mass-pull-request/mass-commit. - Extend the fedpkg CLI to support more actions on pagure, e.g. finding out who is the current package maintainer of Foo or forking the package Bar and sending a PR back. Hope all of this makes sense and would be something that is worth pursuing. Cheers, Dan
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
