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. On Sat, Feb 12, 2022 at 8:13 PM Kevin Kofler via devel < devel@lists.fedoraproject.org> 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
