On Wed, Jun 22, 2022 at 11:08 AM Hunor Csomortáni <csomh@xxxxxxxxxx> wrote: > > On Mon, Jun 20, 2022 at 1:46 PM Vitaly Zaitsev via devel > <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > On 20/06/2022 10:47, Petr Pisar wrote: > > > I think Aleksandra wants to (non-scratch) build all pull requestes before > > > merging. > > > > Official non-scratch builds for non-merged pull requests? Looks very > > dangerous. > > I actually think it's a good idea. Actually, it's not. There are multiple good technical and legal reasons to not do that. > Scratch builds always sounded like a strange idea, mainly b/c it's > forcing us to decide if the output of a build is going to be released > *before* the build is triggered, when it's impossible to tell whether > that output is going to be release-worthy at all. > > I can imagine a setup where the build system doesn't differentiate > between builds. There are just builds. And the update system (or > something else) is where the decision is taken to promote a build as > an update or not, *after* the output of the build is known. When a > build is released, it's marked in the build system as "official". Strange - what you're describing here is what we already have: Gating (for Rawhide) and the updates-testing repo (for stable releases). Those two mechanisms provide exactly the "bless this as good" mechanism for "official" builds that you want. If a build doesn't pass gating tests, or is voted down in bodhi, it won't be pushed to buildroots or to users. No scratch builds involved. In my understanding (and this is also how I use them), scratch builds are just that - test builds that can be thrown away. Most of the time, I just need to test whether a build succeeds in koji, most often because I need to test an architecture that is very slow to emulate locally. It's "nice" that PRs on src.fp.o trigger test scratch builds, just because it tells me whether the change actually builds or not. But the idea to reuse such test builds as "official builds" has never even crossed my mind. Additionally, *IF* we'd want to do something like that, we'd need a *very strict* policy that determines exactly *which* scratch builds would actually eligible for being "promoted" to an "official build": - was it built against the correct buildroot (i.e. fNN-build or a valid side tag)? - was it built recently enough (i.e. there haven't been any SONAME or Python or Perl or X version bumps that would affect the build in the meantime)? - was it built from the correct dist-git repo (i.e. not a fork)? - or if it *was* built from a fork, has the commit also been merged into the correct dist-git branch? - is the commit it was built from on the correct dist-git branch (i.e. the branch matches the target release)? - was it *DEFINITELY 100% SURE* not built from a manually uploaded SRPM file? - etc. At this point, I'd wager most scratch builds wouldn't even qualify. :) Fabio _______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
