On 15/10/21 20:22, Adam Williamson wrote: > On Fri, 2021-10-15 at 14:04 -0400, Ben Cotton wrote: > > Many fewer blockers than last week. Hooray! Go/No-Go for target date > > #1 is Thursday. > > > > > > Action summary > > ==================== > > > > Accepted blockers > > ----------------- > > > > 3. plasma-discover — Discover shows a misleading state of Flatpak > > repos, can't delete disabled repos — NEW > > ACTION: Maintainers to fix issue > > > > 4. plasma-discover — Discover doesn't seem to find any RPM packages, > > neither locally installed nor in RPM repos — NEW > > ACTION: Maintainers to fix issue > > > > 5. plasma-discover — Toggling repo in Discover doesn't redraw the > > checkbox, confusing users — NEW > > ACTION: Maintainers to fix issue > So I'm pretty worried about these. I've spent the last two days trying > to fix 3 and 5 myself, but I'm just not a Qt C++ developer so it's > pretty tough sledding. I basically understand the problems in both > cases, but fixing them is more work. I have put detailed notes in the > upstream bug reports, and I'm happy to compare notes with anyone who > wants to try and help: > > https://bugs.kde.org/show_bug.cgi?id=443455 > https://bugs.kde.org/show_bug.cgi?id=406295 > > #4 is odd as it seems to behave differently for different people at > different times; we haven't figured out the condition that causes the > 'bad' state yet. > > Nobody else appears to be trying to help. I'm not confident we are > going to have these fixed in time. > -- > Adam Williamson IMO, those bugs should have never been approved as Release Blockers. They are bugs that are already present in previous releases (F34 for sure) and, while it would be nice to have them fixed sooner or later, they should not block F35.

So, by that thought, if a bug meet the blocking criteria but have not been caught in the previous release by a mistake of the team (as no one pointed before as blocker bug) that bug can no more be blocker?

On 16/10/21 22:15, Geraldo Simião Kutz wrote: So, by that thought, if a bug meet the blocking criteria but have not been caught in the previous release by a mistake of the team (as no one pointed before as blocker bug) that bug can no more be blocker? That's my opinion. If the bug is already present in a previous release why it should block the next? If no one had never reported or even noticed the bug in the previous version I doubt it should be considered a blocker. In this specific case, I used to have a bare metal machine which had been updated during years between Fedora releases. I was using F34 on that old machine and I never noticed neither the plasma-discover or the KScreenLocker bugs. I then upgraded my PC, installed F34 from clean and started noticing those bugs. I can live with them during my everyday workstation usage, certainly they're annoying (especially the KScreenLocker bug, the plasma-discover bug has disappeared after some upgrades), but that wouldn't prevent me from upgrading to F35. I must also add that, searching in the web about those bugs, I can found users hitting them long time ago. But KDE never fixed them. I also tried to upgrade KScreenLocker to the next available version (available only in F36) and only partially fix the problem. So, if we had to wait for KDE to fix those bugs, we are going to delay F35 release for a long time... Mattia _______________________________________________ kde mailing list -- kde(a)lists.fedoraproject.org To unsubscribe send an email to kde-leave(a)lists.fedoraproject.org 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/kde@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

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 _______________________________________________ kde mailing list -- kde(a)lists.fedoraproject.org To unsubscribe send an email to kde-leave(a)lists.fedoraproject.org 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/kde@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure