Re: Inadvertent mass-rebuild triggered soname bump in libnfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Jan 26, 2025 at 4:40 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote:
>
>
>
> On Sat, Jan 25, 2025 at 12:24 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
>>
>> On 24. 01. 25 22:13, Adam Williamson wrote:
>> > Note that side tags aren't the only issue. Sometimes a maintainer
>> > commits a bump to git but doesn't build it in a side tag or rawhide,
>> > for whatever reason. Sometimes a package is*built*, but gated from
>> > Rawhide by automated tests, but then the mass rebuild effectively
>> > overrides the gating (we found several cases like this). Just checking
>> > side tags isn't gonna catch everything. I really think the appropriate
>> > check is 'was the build most recently tagged into fXX built from the
>> > current git commit? if not, don't rebuild this package, yell for manual
>> > intervention'.
>>
>> Generally, this sounds like a good idea.
>>
>> However, note that is is not uncommon for (proven)packagers to commit stuff
>> that will only eventually get built. We might discover that the number of
>> packages that we yell at for no good reason is too high.
>>
>> As an example of a big chnage, I think the SPDX commits were pushed but not built.
>>
>
> It's possible that I'm in the minority here, but I honestly don't think anything should be pushed to dist-git unless it's intended to be built more or less immediately. Yes, even changes without an immediate functional impact like the SPDX changes.
>
> That said, I agree with Kevin that we should have the compose reports list anything in the compose whose state is "The commit at the HEAD of the `rawhide` branch does not match the commit used for the latest build in Rawhide" and treat that as a bug (ideally, we'd open one automatically) that must be resolved prior to the next mass-rebuild (either by getting a build done or tagging the bug in some way that indicates that it's okay for the mass-rebuild to build it). Anything still on the list when the mass-rebuild is ready to start should be skipped and the bug should be marked as a blocker for Beta (to make sure it gets looked at). Detecting this should be fairly easy, albeit adding a bit to the Koji API load.

I agree. I don't think anything should be pushed into dist-git that
isn't built for rawhide for like ... maybe > 3 weeks (or built in
side-tags and not submitted to bodhi in a similar time-frame). Mass
changes like the SPDX migration shouldn't be a special case here -
after all, the spec file changes will never end up in repositories if
they're pushed but never built.

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, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux