On Wed, 2013-07-10 at 12:09 -0400, Peter Jones wrote:
> Is LXDE considered a release blocking desktop? I honestly
> 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
> 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.
I'm honestly not entirely sure what you mean by this. Could you explain
it again using short, monkey-friendly words? :)
When writing new criteria, or when doing the major re-write we did for
F19, the approach we take (or at least the one I take, for sure) is
simply to try and identify an attribute a Fedora milestone must have to
make it fit for purpose, and codify that in text. That's really it. The
concept of "whether we've unexpectedly lost functionality from the
previous release" is not one that I consciously, at least, hold in mind
when working on the criteria.
That doesn't mean that the release criteria as they stand
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
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".
I certainly concur with this. The question we should be answering is
simply 'do we consider ARM to be worthy of being a PA yet?', and the
release criteria are not intended as a tool to help answer that
question. Rather, if the answer to that question is 'yes' but the
release criteria are not in line with a world in which ARM is a PA, we
should amend the release criteria. They are certainly not set in stone.
And I think right now, the assumption from outside the ARM team has
that for ARM as a PA, we do want functionality to have parity with other
PAs, and so yes, that infrastructure should be ready.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora