Bug 972250
Summary: | Release notes in Lost&Found KDE menu | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | nucleo <alekcejk> |
Component: | fedora-release-notes | Assignee: | Pete Travis <me> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 19 | CC: | awilliam, bcotton, david, dennis, kevin, me, nb, rdieter, robatino, sgordon, sparks, wb8rcr, zach |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | RejectedBlocker AcceptedFreezeException | ||
Fixed In Version: | fedora-release-notes-19-0.12 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-06-18 06:19:28 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 834091, 946926 |
Description
nucleo
2013-06-08 00:46:41 UTC
I think this violates the "menu sanity" criterion => nominating as blocker. arguably, though note i'm proposing that we downgrade those criteria quite a lot: https://lists.fedoraproject.org/pipermail/test/2013-June/115891.html follow-up to that thread please, just wanted to alert you :) I think it's good to take care of polish stuff like that, but it doesn't necessarily make a lot of sense to block the release on it. The .desktop file uses "Categories=Documentation;" - it seemed the most appropriate. I can change it "System;Documentation;" or even "System" to restore the previous behavior, but I'd much rather see KDE properly support the Documentation category. Per the desktop-menu-spec: http://standards.freedesktop.org/menu-spec/latest/apas02.html Documentation is an Additional Category and MUST be used together with a Main Category from the list in: http://standards.freedesktop.org/menu-spec/latest/apa.html#main-category-registry (System, i.e. "Categories=System;Documentation;", is a valid option). Adam Williamson wrote in comment #2: > I think it's good to take care of polish stuff like that, but it doesn't > necessarily make a lot of sense to block the release on it. And I think this is very broken, we should have MORE "polish" criteria to cover the things we don't currently cover, not less. At least unless you're planning to do live image respins with updates. The live images look very unpolished and broken if we release with known defects in that area. well, it's a pragmatic thing: i don't think the will is really there across the project to support such a move. it doesn't pass the release blocker 'acid test': if we got to the go/no-go meeting and all that was left was a couple of polish bugs in the menus, I don't think we'd be able to swing a 'no go' vote. so there's no point in pretending we could. (In reply to Kevin Kofler from comment #4) > Per the desktop-menu-spec: > http://standards.freedesktop.org/menu-spec/latest/apas02.html > Documentation is an Additional Category and MUST be used together with a > Main Category from the list in: > http://standards.freedesktop.org/menu-spec/latest/apa.html#main-category- > registry > (System, i.e. "Categories=System;Documentation;", is a valid option). Thanks for pointing this out, Kevin. I was interpreting the spec as "Compliant Desktpo Environments must support Main categories, and can optionally also support these additional categories" instead of "Compliant Desktop Files..." Discussed at 2013-06-10 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-10/f19final-blocker-review-4.2013-06-10-16.01.log.txt . With a closer look at the existing criteria, this still doesn't actually hit them. It says all Applications must launch (kinda irrelevant here), everything has to have a good icon (not the issue here), and nothing can be listed twice - but it doesn't say anything about things not being in the right place. And if we just disregarded the letter of the criteria and considered whether we thought we really ought to block a release over this bug, the consensus was no, we probably wouldn't. But it does look pretty silly, so obviously it'd be best to fix it, and we certainly would be happy to do that post-freeze, so it's rejected as a blocker but accepted as a freeze exception issue. In practice the fix is simple and we still have some time before release, so it shouldn't be a problem to get this fixed at all. IMHO, anything showing up under "Lost&Found" SHOULD be a blocker! We are being paranoid like crazy about updates, yet we are willing to release live images with such blatant defects. (What if such a regression were introduced much later in the freeze? This one did sneak in post-Beta.) fedora-release-notes-19-0.12 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/fedora-release-notes-19-0.12 Package fedora-release-notes-19-0.12: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing fedora-release-notes-19-0.12' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-10839/fedora-release-notes-19-0.12 then log in and leave karma (feedback). fedora-release-notes-19-0.12 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. Release Notes again in Lost&Found menu on F20 Alpha RC2 KDE image. fedora-release-notes-20-0.0 |