"Richard W.M. Jones" <rjones@xxxxxxxxxx> writes: > I always think that Fedora works fine if you maintain 1-5 packages. > It's possible to maintain 20 with a lot of work. And if you want to > maintain 100+ (things like the ocaml-* set that I help to maintain) > then you have to write your own automation. Could we do things > better? No one asked for them, but here are my ideas ... > > --- > > * kill the %changelog > > Please, let's kill it, and generate it from the git changelog. > I'm glad to see there's a proposal to do this. > > A general principle I'm following here is a packager should never > be asked to enter the same information twice. > > * committing to git should build the package > > Is there a reason why this wouldn't be the case? Not really no. I've been involved quite a bit in building packages on openSUSE's Buildservice and every commit there results in a rebuild. So it is doable, *but* OBS has the advantage that it discards all builds except for the most recent successful one, or it would have run out of storage ages ago. Although someone (Randy Barlow maybe?) had the idea to generate the changelog and to trigger builds from git tags instead of commits, which has a certain charm to it as well. If there was a choice whether to trigger builds from commits or tags and how to generate the %changelog, then I think that most use cases should be covered? > > * commit groups of packages together > > One reason why automatic commit -> build might not be desirable is if > you're trying to build a group of packages in a side tag. In my > opinion this means we should allow groups of packages to be committed > together. (Unfortunately because we chose to put every package in its > own git repo, the obvious way to do this can't work, but we could > still have a "ChangeId:" header in the commit message that ties > packages together). > > The packages should be built in build dependency order into a side > tag, and the side tag turned into an update, with no further > involvement from the packager unless something fails to build. > > This change on its own would solve the main problem that > affects people maintaining large sets of packages. How about something like `fedpkg add-to-side-tag` (yes the name needs work) that would work like this: $ fedpkg request-side-tag $ fedpkg add-to-side-tag $tag_name $pkgA $pkgB $pkgC $pkgGlob Now all git commits/tags pushed to $pkgA $pkgB $pkgC $pkgGlob result in them being built in the side tag $tag_name by default. Once the side tag is merged, you go back to building the "ordinary way". > > * “Fixes:” etc headers in git > > RHEL already does this. It should be possible to add special headers > to the commit message to automatically close bugs, ie: > > $ git commit -m "ocaml: Update to version 4.10.0 > Fixes: RHBZ#12345" > > Note the build, update and bug closing would happen completely > automatically, assuming there was no build or test failure. +1 on this one. > > * CVE bugs should autoclose when a package is rebased I don't think this is a good idea as you should actually check that this update fixes the CVE. 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
