On Wed, Jul 10, 2013 at 07:45:53AM -0400, Josh Boyer wrote:
On Wed, Jul 10, 2013 at 6:02 AM, Jaroslav Reznik
> I don't see a problem with different set of blocking desktops for ARM, even
> as primary architecture. But it's really about resources - do we have people
> willing to work for example on LXDE (I'd say more resources friendly for
> current ARMs) - not saying there are no people, but more to support it as
> blocking desktop, if QA would be able to validate three desktops on two
> different platforms... And as we try to avoid "default" world in Fedora
> let's have LXDE "default" in some cases.
Is LXDE considered a release blocking desktop? I honestly don't know.
I also don't think it matters whether LXDE or FVMW2 or Gnome is the
default desktop on ARM. The criteria should probably be that it ships
with a desktop that is considered release blocking. If LXDE isn't
one, then perhaps it should be made so. The goal here shouldn't be
"we have a desktop". It should be "we have a desktop experience that
is the same on all primary architectures". To that end, whichever
desktop is picked should be release blocking and it should function
the same on all primary architectures.
There's sort of a more central issue here that's causing this question -
while the release criteria certainly are meant to be a way of evaluating
if the release is complete and functional, there's some creep in of how
we use them because of how they were developed. Specifically, what
they're implicitly testing is whether we've unexpectedly lost functionality
(or quality) from the previous release. Obviously that's not quite the
metric in which we'll be evaluating arm as a PA.
That doesn't mean that the release criteria as they stand aren't good
for ARM - but they're criteria for evaluating RCs, not the criteria for
ARM as a PA.
It's two different things, and it's important that we not confuse them.
The question isn't "is $DESKTOP not working a release blocker" - it may
or may not be. The question is "is the infrastructure for normal
desktops to work required to be a PA".
And I think right now, the assumption from outside the ARM team has been
that for ARM as a PA, we do want functionality to have parity with other
PAs, and so yes, that infrastructure should be ready.