On Wed, Nov 16, 2022 at 02:09:47PM +0100, Kevin Kofler via devel wrote: > > 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. You're welcome to bring anything you like to me. (That goes for everyone!) That said, it doesn't mean I have to agree with you or do what you want. > 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. Indeed. That might be an indicator that not so many people agree with you? > > 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.) With my packager hat on, yes, I am completely fine with bodhi telling me that. > 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. I agree that bodhi is a complex application, but I disagree most strongly that the solution is to just make it not do all those things that I find useful and desireable. > > 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. I think the current situation is much better than what we had then. Blocking updates that break things is desireable, they will be fixed sooner and not break everyone else that is trying to integrate their changes. We can of course make things better, but I don't have any desire to go back to the "good old days". Anyhow, I am done, feel free to get the last words in the thread. :) kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
