Stephen Smoogen wrote: > On Tue, 15 Nov 2022 at 16:04, Kevin Kofler via devel < > devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > >> Kevin Fenzi wrote: >> > I think we are going to just have to agree to disagree here. >> > >> > I think we have had this discussion a number of times now and aren't >> > going to convince the other. >> >> So Bodhi will continue to become more and more unmaintainable due to >> piling >> up more and more complicated rules that it needs to enforce, and obvious >> defects such as the one that started this thread will never get >> addressed. >> >> It is really sad that you are not willing to open your eyes and see the >> amount of damage that this dead-end policy has caused and is still >> causing. >> >> > Could you possibly pick the fight with the right people for once? It > doesn't matter if Kevin Fenzi agreed with you because he isn't the person > who a) writes the guidelines which were asked to be implemented or b) > works on bodhi codebase in any way. He just makes sure it and the other > 240 services runs and that the builds generally flow. That already takes > up about 60 hours of his work week. > > If you have problems with this please bring it up with FESCO and the > Fedora Packaging Committee and probably the Council. Kevin Fenzi is currently a member of FESCo (see https://docs.fedoraproject.org/en-US/fesco/) and has been in that role for years. So pushing the blame off to "someone else" is not going to work. And I have brought this issue to FESCo (which is where most of the update policies came from, not FPC or the Council) more than once. Usually, it was not even brought to a vote. And whenever there was a vote about the issue, it was always in favor of either the status quo or even stricter rules. > They are the ones who over time have listened to packagers, users, and > developers about what was expected from the build system And that is exactly what I am disputing, that they are listening to what packagers expect. Because it can surely not be the packagers' wish to have some piece of software stubbornly dictate that no, that package can not be pushed to stable now because it reached testing only 6 days, 23 hours, 59 minutes and 59.999999 seconds ago. (I believe the timestamps in Bodhi have microsecond resolution internally. They used to be displayed that way, at least.) Nor can it be in the interest of the Bodhi developers to have to maintain all that complex logic: you pointed out yourself that "what happens is that you will get into about 1/3rd of the way into it and find you have now to add a bunch of new requirements" – surely that is not what the developers expect. > and they are the ones who have given general guidance over the last 10+ > years of bodhi development. If by "general guidance" you mean skyrocketing requirements, then I agree. Otherwise, I don't, sorry. See above, you admitted yourself that the requirements keep increasing all the time, forcing a major refactoring. These days, even Rawhide (!) gets forced through Bodhi, though with an entirely different workflow (but in turn, that means the Bodhi developers get to maintain 2 completely different workflows with completely different rules). That is something Bodhi was never designed for. And the policy changes that have been made for Rawhide over the years have also changed things for the worse: It used to be that you were able to just do development in Rawhide, without having to bother about broken dependencies (which would just show up in the daily dependency report and get fixed there: I remember provenpackagers, mainly Alex Lancaster and me, mass- rebuilding packages to fix broken dependencies; Rawhide composes did NOT fail due to broken dependencies at the time, the deliverables that failed to compose would just be missing that day), upgrade paths (from Rawhide to Rawhide, really no reason to not just let the users use distro-sync there and allow the version to go backwards; upgrade paths make sense only for releases), test failures (Rawhide was expected to be broken, as is normal), etc. Now we just make life harder for everyone, both package maintainers and Bodhi developers, for no reason. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
