On Thu, 2013-12-12 at 20:30 -0600, Michael Catanzaro wrote:
> On Thu, 2013-12-12 at 21:12 -0500, Rahul Sundaram wrote:
> > Really? We don't want to even make sure the apps that we ship by
> > default in the DVD image starts? Why are we even bothering to ship
> > those additional apps then? Include in the DVD image the same set of
> > apps that we include in the live images (from GNOME and KDE) and
> > nothing more then.
>
> My $0.02: I'm surprised this change is even being considered. If the
> application is completely broken, and it is not important enough to be
> on the live CD, and it is not important enough to fix before the
> release, then the application should be dropped from the default
> install: blocker resolved! If it's important enough to remain in the
> default install, it's also important enough to block the release.
>
> A basic functionality test is, well, basic, and Fedora shouldn't install
> something by default that's known to be completely broken. It also
> doesn't make any sense for a DVD installation to secretly result in a
> lower quality desktop than a live CD installation. (Well, it doesn't
> really make sense for the DVD installation to include more packages,
> either, but that's a separate issue.)
It never turns out to be quite so simple in practice.
The specific bug here is:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1040922
it was -1'ed at go/no-go meeting in about five seconds. No-one voted +1
blocker on it. We are clearly not, as a project, willing to block
releases on this. Yet it clearly violates the current criterion as
written. This must be resolved somehow.
The complicating factors here: the 'application' in question isn't
really an application so much as it's a convenience wrapper around one
of the dozens of bits that go to make up kipi-plugins. It's not actually
totally broken, because if you somehow run it against some image files -
run it from a command line, or use it to 'open with' some image file or
other - it works.
It doesn't do anyone any good for us to write something in our criteria
that the project is not actually willing to stick to; in practice, this
criterion is not passing the 'do we slip a week to fix absolutely any
violation of this criterion' test. We don't. So, we have to do something
about that.
Please do post any alternative suggestions that resolve the tension...
BTW, if you haven't done a KDE install from DVD, go do one and look at
the menus. I think there's over 100 things in there. It kinda gives you
a different perspective on whether this criterion is realistic. The
'desktop_menus' test that enforces this criterion is very rarely run,
and even *more* rarely by anyone other than me. If people aren't willing
to sit there clicking on every one of the 100+ items in the KDE menus
often enough that we catch this kind of bug early enough to do something
about it, we cannot maintain the criterion; we can't retain criteria we
don't have the resources to police properly.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net