release criteria revisions
mclasen at redhat.com
Mon May 9 17:20:18 UTC 2011
James has asked me to write something about the desktop-related release
criteria in the light of bug
Starting with the bug itself, I'll state that I don't think it is a
blocker that we should fix for F15. It has made it to the blocker list
because it seems to violate the release criterion that there shall be no
'Other' menu in the panel menus.
Why did we put this in the release criteria ? Selecting from a long menu
is difficult, you can't actually see the content hidden behind the
menuitem until you perform a reasonably hard fine-motor-control task,
and it is hard to back out of submenu should it not contain what you are
In fact, these difficulties with hierarchical menus were one of the main
underlying motivations for the design of the shell overview. Not
surprisingly, the shell overview does not have these problems, mostly.
The primary mode of interaction with the overview is search; you just
The presence of the unsorted 'Other' grab-bag category is still an
annoyance, but since categories are much less prominent, it is just a
Looking at the rest of the 'Menu sanity' bullet points in
https://fedoraproject.org/wiki/Fedora_15_Final_Release_Criteria some of
these codify the GNOME2 user experience and are not really adequate for
> All Applications listed in the desktop menus must have icons which
> have a consistent appearance and sufficiently high resolution to avoid
> appearing blurry
No problem with this one, although it should really be a bit more
concrete: the shell overview works best if the application icon is
available as a 256x256 png.
> All applications listed under the Applications menu or category must start
No doubt still relevant.
> All applications listed under the Applications menu or category must withstand
> a basic functionality test and not crash after a few minutes of normal use.
> They must also have working Help and Help -> About menu items
This one needs revision or clarification, I think. First of all, talking
about menu items only makes sense if one assumes a classical
menubar-toolbar-content-statusbar application layout. The developing
GNOME3 HIG will de-emphasize this pattern in favor of menubar-less
designs. And even if an application does have a menubar, maybe it does
not need help because it is very obvious ?
Wrt. to 'About', one thing we are aiming for in GNOME3 is to have
'unbranded utilities' which are part of the core desktop. 'About'
dialogs mostly make sense for applications which have a 'personality'
and are not just part of the desktop. In short: applications can have an
about dialog, but the shell overview also shows things which are not
applications in that sense.
Last question on this criterion is: What is the consequence ? If an
application does not have an about dialog, do we really expect to hold
the release until the packager has patched one in, collected the
necessary translations, written a manual, hooked it up, etc ? This
really feels more like a criterion to consult when choosing the
applications to include on the spin.
> There must be no Other menu or category
I've already talked about this. I really don't see us block a release
for this, but having meaningful classifications for all applications is
certainly a useful thing to keep in mind somehow. In fact, I think that
would be a more useful criterion.
> No application may unintentionally appear twice in the menus. In particular,
> items under System must not appear under Applications
This basically does not apply to the shell overview. It does not have
the Applications vs System dichotomy, and I think allowing overlapping
classifications would actually be a very useful thing in the overview;
if not for the fact that the desktop entry spec codifies mutual
exclusion for primary categories, IIRC.
More information about the test