On Tue, Jan 28, 2020 at 11:51:29PM +0100, Dan Čermák wrote: > "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? The original idea of using git tag is Jeremy Cline's. If we support: automatically building from commit or not, then I don't think we need to support building from git tag, using the current approach would work just as well when you don't want to build from commit. > > * 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". Isn't that just fedpkg chain-build --target=$tag_name ... ? This is already existing and working, however, it requires the different packages are up to date in git (ie: you've made and push the commit updating the spec file to the next release/version) which goes against the point above about automatically build on commit. Pierre
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
