Kevin Fenzi wrote:
> As a release engineer trying to get a rawhide compose, I do find this a
> big deal. (Another f37 compose just failed because of this issue).
Well, as I already pointed out more than once, the real issue there is that
the Rawhide compose fails due to a broken dependency. This used not to be
the case. If a deliverable fails to compose, then it will be missing for one
day (or ideally, just keep the last one that built on the mirrors!). If it
is release-blocking, it needs to be fixed before the release. Not sooner.
This is how things used to work in the past (without the "or ideally" part,
that is just my improvement suggestion that was never implemented) and it is
why we were able to work much better with broken dependencies in Rawhide
back then than now.
> Long ago we worked that way. Back when there were few packages and few
> maintainers.
The number of packages increases constantly, but the order of magnitude was
not that different. What really made the difference was that the composes
did not fail. Instead, they would succeed and we would automatically get a
list of broken dependencies sent to the devel list (and then provenpackagers
like Alex Lancaster and me tried to mass-fix them, and IMHO did a very good
job at it, until, in lieu of a "thank you", we were told not to because it
"masks the issue of unmaintained packages"… that was the point at which
broken dependencies started to accumulate, creating the demand for gating).
> Keeping rawhide working helps everyone who is trying to use it to
> integrate their changes.
The requirement to keep Rawhide working prevents using it to integrate
anything non-trivial, forcing everything into side tags (which then moves
the conflicts to the point where the side tags get merged, which can cause a
big mess if they happen to overlap too much).
> Dumping breakage into rawhide and expecting others to clean it up makes it
> harder for almost everyone.
"Others" (including me) were quite happy to clean it up until we were
explicitly told to stop!
Kevin Kofler
_______________________________________________
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
