On Sun, 2021-10-17 at 08:55 -0300, Geraldo Simião Kutz wrote:
Ok, I understand the point, I too have lived with some of these bugs
and
don't noticed them until now. It's fair to move on and don't hold the
release hostage as Matthew said, but for that I think we should add some
rule, policie or something to the release blocking criteria allowing that,
because most of these bugs meet one or other criteria and we must be
consistent.
You can make an argument against the repo enable/disable bugs even on
the merits, honestly. We seem to be rather expanding our definition of
'critical functionality' lately. When we first wrote that criterion, I
don't think we would've expected it to cover "visual issues with
flatpak/fwupd repo enabling in the package manager", but at least three
people voted that way this time, so the bugs got accepted. It's
reasonable for someone - especially someone from KDE SIG - to say hang
on, we wouldn't have voted that way, can we please re-vote it? If
someone does come to a meeting or ticket with a reasonable argument
against the decision, we can re-consider it. We have plenty of
precedent for re-voting blockers based on new information (like "it's
been broken for years and apparently nobody cared a lot") or reasoning
("is this really critical functionality?")
I do think that if we're going to go hard on package manager
functionality as release-blocking, it might be a good idea to extend
the explicit criteria, rather than rely on the 'critical functionality
test' wording. Honestly, when we first wrote that criterion, for a
package manager I would've expected it to cover "run the app and
install a package", I wouldn't really expect it to go as far as
covering the repo configuration bugs we currently have as blockers.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net