Hi,
first of all, I would like to apologize for the mess I've caused by the jasper .so name bump in Rawhide. I entirely forgot the side-tag option and had the old mindset of having rawhide as a "sandbox for new features". I wrote to Miro already as I am not part of the proven packager group to assist me with the update - specifically with package rebuild.
On the other hand, I have to partially agree with Kevin Koffler in the way that making library upgrade in the rawhide from a regular maintainer point of view is still quite painful and from discussion with my colleagues it seems that I am not the only one who feels it that way.
Mostly, simple rebuild of dependent packages is all that is needed, but to achieve it, I have to either communicate with all other maintainers (where their number might be quite huge and not all of them are able to react in meningul timeframe - agree it's not applicable with handful of dependent packages, where it is easy to get it done) or bother some proven packager to do the rebuilds on my behalf (which is something I don't like, as the workload is transferred to someone, who has enough of his/her own tasks already).
It would be awesome to have some bot available for all Fedora maintainers, which would have proven packagers rights and it's only function would be -> bump spec file and build (e.g. in specific side-tag). In that way, for most library updates this would be the easiest way, how to get them into Fedora and bother other maintainers/proven packagers as little as possible.
Best regards
Josef Ridky
Senior Software Engineer
Core Services Team
Red Hat Czech, s.r.o.
Senior Software Engineer
Core Services Team
Red Hat Czech, s.r.o.
On Sat, Feb 12, 2022 at 8:13 PM Kevin Kofler via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
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
_______________________________________________ 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
