Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> writes: > 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. Building from a git tag would have the advantage, that each build would show up on pagure under the "Releases" tab, albeit that is probably just a cosmetic advantage. > >> > * 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 ... ? Could be, I've never used it. > 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. Well, my idea was that you tell the infra: "hey, from this point onward (until the side tag is merged or I turn it off), I want every commit to be built in the side tag".
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
