Re: Inadvertent mass-rebuild triggered soname bump in libnfs

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

 



On Sat, Jan 25, 2025 at 12:13:02PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> On Sat, Jan 25, 2025 at 12:32:52PM +0100, Fabio Valentini wrote:
> > On Fri, Jan 24, 2025 at 10:13 PM Adam Williamson
> > <adamwill@xxxxxxxxxxxxxxxxx> 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'.

In fact, I wonder how hard it would be to generate every some time
frame/on demand/before mass rebuild the list of packages in this state?
Or perhaps even just run it every compose and add a section to the
compose report about it? 

I think in general stuff shouldn't stay in this state very long (but of
course people are busy, sometimes things need discussion with other
packagers/upstreams, etc). Just knowing about them could be helpfull
tho.

> > Thank you, this actually seems the only actionable / workable
> > suggestion in this thread so far.
> > I agree that there's likely not going to be a "one-size-fits-all"
> > automated solution here.
> > While bailing out, skipping the package, and requesting manual
> > intervention should always "work".
> > Adding the required checks might slow down submission of builds during
> > the mass rebuild further, though.
> 
> I like this approach too. In fact, it'd be safe for the mass rebuild
> script to add the mass rebuild changelog entry, i.e. do everything
> except firing off the build. Then the maintainer would only need to
> do 'git pull && fedpkg build' if everything is OK.

I guess you mean for the case where something was built before the mass
rebuild, but stuck in gating/side tag and should be rebuilt with the
tools from the mass update? I suppose that makes sense...

kevin
-- 
_______________________________________________
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