On Wed, Jan 29, 2020 at 10:04:32AM +0100, Pierre-Yves Chibon wrote: > 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. Needs to be something which builds in BuildRequire order to solve the actual problem. Also AIUI fedpkg chain-build doesn't work except in Rawhide, although I'm not sure why that is? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org _______________________________________________ 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
