Hi, folks. I wanted to ask if you envisage a need for release criteria for Workstation at Beta (or Final) over and above those that already exist for 'desktop' stuff. Areas I notice:
SSSD is listed in the tech spec. We have server-side requirements for FreeIPA in the Server product; do we want to formulate client-side requirements?
We don't really have criteria relating to a11y or complex input methods; this isn't Workstation-y in particular, but something that might be interesting?
Appearance is something we'd want to enforce if it were actually done, but I get the impression the Qt variant of Adwaita isn't actually written yet.
Functional requirements for the 'core apps' - we have requirements for graphical updating (but not package install), web browser, and terminal in the current criteria, but not for text editor, file manager, Boxes, or 'developer assistant'.
Do remember that anything we write in the release criteria is something we expect to enforce: if you don't actually want the release to be delayed if it's not done, best not to have a criterion for it. More aspirational 'to-do' or 'it'd be good if...' lists can be handled somewhere else, I don't know/care where, but not in the criteria :)
Thanks folks!
"All applications installed by default in Fedora Workstation must comply with each MUST and MUST NOT guideline in the Applications and Launchers policy." [1] (This is already mentioned at the very bottom of the policy.)
On Mon, 2014-09-29 at 17:27 -0700, Adam Williamson wrote:
We don't really have criteria relating to a11y or complex input methods; this isn't Workstation-y in particular, but something that might be interesting?
a11y is a good target not just for release criteria, because it is absolutely essential for a few users, but also for a test plan, since an a11y regression is quite likely to be missed by developers.
Appearance is something we'd want to enforce if it were actually done, but I get the impression the Qt variant of Adwaita isn't actually written yet.
This may be too subjective for a release criterion. How would we phrase it? "Qt apps must not look terrible" doesn't seem quite right....
[1] https://fedoraproject.org/wiki/Workstation/Guidelines/Applications_and_Launc...
On Mon, 2014-09-29 at 20:41 -0500, Michael Catanzaro wrote:
"All applications installed by default in Fedora Workstation must comply with each MUST and MUST NOT guideline in the Applications and Launchers policy." [1] (This is already mentioned at the very bottom of the policy.)
That sounds workable, so long as someone's actually making sure we *do* comply with those. Has anyone checked that yet? I'd rather not throw it in the criteria and then have to fudge it immediately :)
We used to have polish criteria for the desktop, and then we'd inevitably find issues late in Final testing and no-one would want to block release for them, it got to be a bit absurd, which is why we dropped those criteria a couple of releases back. I'm fine with having them, but it needs a concerted effort to actually live up to them, and to really consider them to block the release.
On Mon, 2014-09-29 at 17:27 -0700, Adam Williamson wrote:
We don't really have criteria relating to a11y or complex input methods; this isn't Workstation-y in particular, but something that might be interesting?
a11y is a good target not just for release criteria, because it is absolutely essential for a few users, but also for a test plan, since an a11y regression is quite likely to be missed by developers.
Appearance is something we'd want to enforce if it were actually done, but I get the impression the Qt variant of Adwaita isn't actually written yet.
This may be too subjective for a release criterion. How would we phrase it? "Qt apps must not look terrible" doesn't seem quite right....
The Tech Spec I was reading as I wrote my mail (sorry if I didn't make that clear) states that GNOME and KDE must use a unified appearance. That's what I was referring to.
[1] https://fedoraproject.org/wiki/Workstation/Guidelines/Applications_and_Launc... -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
On Tue, 2014-09-30 at 09:50 -0700, Adam Williamson wrote:
On Mon, 2014-09-29 at 20:41 -0500, Michael Catanzaro wrote:
"All applications installed by default in Fedora Workstation must comply with each MUST and MUST NOT guideline in the Applications and Launchers policy." [1] (This is already mentioned at the very bottom of the policy.)
That sounds workable, so long as someone's actually making sure we *do* comply with those. Has anyone checked that yet? I'd rather not throw it in the criteria and then have to fudge it immediately :)
Further note: "the agreed upon "core desktop experience"" *really* needs to be a link pointing to a formal definition of what that includes.
On Tue, 2014-09-30 at 09:50 -0700, Adam Williamson wrote:
That sounds workable, so long as someone's actually making sure we *do* comply with those. Has anyone checked that yet? I'd rather not throw it in the criteria and then have to fudge it immediately :)
I don't think all apps are currently in compliance. There were some issues with high contrast support, last I checked, but those apps may all have been dropped already. And the LibreOffice apps' names are too long.
The thinking behind these requirements is not "the release is blocked until the app is fixed," but "the release is blocked until the app is fixed OR the app is dropped" -- there's flexibility to choose the best approach on a per-app basis. If Weather or Music is still missing a high contrast icon, we'd probably just drop the app and move on with our lives. If the issue is with a more important app outside our control (e.g. if LibreOffice were to regain a dependency on OpenJDK Policy Editor), then the blocker criterion is good incentive for the problem to be fixed.
On Tue, 2014-09-30 at 09:50 -0700, Adam Williamson wrote:
That sounds workable, so long as someone's actually making sure we *do* comply with those. Has anyone checked that yet? I'd rather not throw it in the criteria and then have to fudge it immediately :)
Salutations,
A bit late I know, but I found three issues through the highly-advanced testing process of turning on high contrast mode:
https://bugzilla.redhat.com/show_bug.cgi?id=1130794 https://bugzilla.redhat.com/show_bug.cgi?id=1152792 https://bugzilla.redhat.com/show_bug.cgi?id=1152796
Of the three, setroubleshoot is the only one that's potentially problematic here, since somebody would need to make a new icon and setroubleshoot is arguably important enough to block on (as opposed to simply dropping it). We don't want OpenJDK Policy Tool. GNOME Logs is easy to fix (but I think we do not want that, either).
If anybody finds more issues in the future, we can deal with them as they come. I don't propose revising the guidelines or the release criterion; that they cover these issues simply shows that they solve a real problem for us (in this case, ensuring our high contrast support does not regress).
Michael
On Mon, 2014-09-29 at 20:41 -0500, Michael Catanzaro wrote:
"All applications installed by default in Fedora Workstation must comply with each MUST and MUST NOT guideline in the Applications and Launchers policy." [1] (This is already mentioned at the very bottom of the policy.)
So Beta TC1 request is filed now, and I'd like to get the criteria in place (and then test cases) ASAP. I'm therefore proposing to make this a Beta criterion tomorrow or so if no objections are filed. (We can always adjust later). We can then write a test case for it.
On Mon, 2014-09-29 at 17:27 -0700, Adam Williamson wrote:
We don't really have criteria relating to a11y or complex input methods; this isn't Workstation-y in particular, but something that might be interesting?
a11y is a good target not just for release criteria, because it is absolutely essential for a few users, but also for a test plan, since an a11y regression is quite likely to be missed by developers.
I'd just want to be sure we're actually in shape to enforce any requirements we decide to set. If anyone has a realistic criterion / set of criteria for a11y stuff they'd like to propose, we can certainly look at including that. This has to be stuff we can *actually stand behind* for F21 Beta / Final (as appropriate).
It's generally expected that all release criteria are backed by test cases, there are conventions/templates for both associating criteria with test cases (the References sub-note for all criteria is expected to cite at least one associated test case) and test cases with criteria (test cases that enforce release criteria are expected to include a template which produces an admon/info notice explaining which release criterion they enforce, see https://fedoraproject.org/wiki/QA:Testcase_kickstart_firewall for an example).
So, I'd certainly be intending that we create test cases (or appropriately extend existing ones with the template and categorization, where they exist) for any criteria we add.
On Mon, 2014-09-29 at 20:41 -0500, Michael Catanzaro wrote:
"All applications installed by default in Fedora Workstation must comply with each MUST and MUST NOT guideline in the Applications and Launchers policy." [1] (This is already mentioned at the very bottom of the policy.)
I have now added this to the Final criteria: https://fedoraproject.org/wiki/Fedora_21_Final_Release_Criteria
On Tue, 30 Sep 2014 02:27:00 +0200, Adam Williamson adamwill@fedoraproject.org wrote:
Appearance is something we'd want to enforce if it were actually done, but I get the impression the Qt variant of Adwaita isn't actually written yet.
Hi, It is but I doubt I'll manage to get it done until the deadlines. The current state is packaged here on [1]. F21 packages don't get built for some reason though, so try at least the F20 ones (which should work in F21 too). There's still quite a bunch of stuff to be done - some elements are untouched now, like QTreeView. Some minor touches are needed to be done basically everywhere. Anyway, the good news is, it doesn't crash anymore, as far as I tried. You can even set the theme as default systemwide, although I... don't really recommend doing so at this point.
Martin
desktop@lists.stg.fedoraproject.org
-
Adam Williamson -
Martin Bříza -
Michael Catanzaro