Orion Poplawski venit, vidit, dixit 2026-05-10 03:49:35:
> On 5/8/26 10:00, Fabio Valentini wrote:
> > On Fri, May 8, 2026 at 3:27 PM Orion Poplawski <[email protected]> wrote:
> >>
> >> So, I appreciate the closing of rawhide bugs when builds with BZ #s in
> >> the commit/changelog. But I'm not a fan of the process closing bugs
> >> against branched versions. Is that behavior intentional?
> >
> > So, if you're referring to the brief period where "branched" Fedora
> > releases behave the same as rawhide (successful build -> automatically
> > submitted to bodhi), then no, there's no way that I know of to prevent
> > *both* updates to get marked as "fixing" the bug in the changelog
> > entry.
>
> Hmm, maybe that's it - but I feel like a recent build closed an F44
> build. Which was then annoying because when I went to submit the F44
> update the BZ did not show up because it was already closed. Which it
> really should not have been because it against F44 and it had not yet
> been fixed there.
Well, bodhi closed the bug because you committed a change to the F44
branch together with a commit message which claimed that it fixes the
bug with number xy. So bodhi was right to close bug xy, wasn't it?
Was the commit message right when it claimed to fix that bug when the
commit was for F44 and the bug for rawhide? Yes and no. It depends a bit
on how you view branches and how you use them. Our use of git branches
as both driving "build for release z" and "this is a source/spec change"
mixes bits which are tied to a specific release and bits which are not
necessarily so. Indeed, over the time I came to the conclusion that
diverging branches in dist-git + cherry-picking from rawhide make much
more sense than (fast-forward) merges. In particular, this does not
pull-in "wrong" mass-rebuild commits (which do not hurt but do not
reflect the build history on the "wrong" branch), it's automatically a
new commit whose message you can rewrite, you can reference the
"original" commit easily, and with autospec you avoit bogus merge
conflicts.
The only alternative to diverging branches would be release branches
plus feature branches, then merging the latter selectively to the
former (and, potentially, amending the merge commit with the appropriate
rhbz number). This would be the most gitty way, but so far it does not
work well with our tools ("non-fedora" branches have no release,
autospec with merge commits).
Regards
Michael
--
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it:
https://forge.fedoraproject.org/infra/tickets/issues/new
