On Wed, Nov 16, 2022 at 02:09:47PM +0100, Kevin Kofler via devel wrote:
Kevin Fenzi is currently a member of FESCo (see
) 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
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
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.
That might be an indicator that not so many people agree with you?
> They are the ones who over time have listened to packagers,
> 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
With my packager hat on, yes, I am completely fine with bodhi telling me
Nor can it be in the interest of the Bodhi developers to have to
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
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
> 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
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. :)