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(a)redhat.com> 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