Stephen Smoogen wrote:
On Tue, 15 Nov 2022 at 16:04, Kevin Kofler via devel <
devel(a)lists.fedoraproject.org> 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