[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Fedora 18 issues with translations and keymaps



> Well, yes, in the context of whether we ought to make it into a released
> product yet. :) I didn't say it was a fair comparison. I explicitly said
> it wasn't. But 'is it a fair comparison?' is not the operative question
> in the context of trying to decide 'is what we have releasable?'.

This is just setting us up for stagnation and failure, though.  Such a
comparison means we can't ever ship a significant change unless:

(1) Volunteer support appears to take care of things that we simply
cannot do; or

(2) We wait until the last minute and when such support does not appear,
make drastic changes to deal with the fact that there was no such
support.

Developing this product is an iterative process.  It's never going to be
perfect on the first go-round, and if we keep raising the criteria for
what qualifies as good enough, we are simply never going to be able to
release.  The feeling I'm getting here is that some previous version of
Fedora is the gold standard and anything in anaconda that's different
from that is cause for holding up the release.

> FWIW, I actually looked at them all, and my take is that anything under
> 40% is very likely to be pretty much unusable.

We can consider weeding those out, but you need to consider this
question:  At this point in the release, is this more important than
fixing partitioning bugs/NFS mounts/problems that will hit every single
person?  If not, we should just not worry about it and consider what can
be done for F19.

> we're not doing
> weeding of 'supportable' keyboard layouts in anaconda any more, we're
> just throwing the kitchen sink at the user, but we haven't made sure the
> selected configuration can actually be applied properly (viz the console
> layout problem).

Years of handling "my favorite keyboard layout isn't supported!" bugs
means we are now just providing everyone everything.

> I agree that the fix for that is that we should be able
> to use xkb keymaps on the console, but if that doesn't happen - if
> no-one actually writes that code - then what we have is a significant
> functional regression. Ditto the issue of mapping countries to
> keyboards: I agree that we want to be doing as little of that as
> possible in anaconda, but if no-one else takes up the slack, then what
> we get is worse than what we had. To a large degree this is "not your
> problem", but it _is_ Fedora's problem, and I fully intend to keep
> making a nuisance of myself all over the place until the magic upstream
> sources for this information actually appear. :)

I don't think there's been much motivation for anyone to come up with a
better solution, given that there's been an awful lot of good-enough
type stuff floating around.  Perhaps now there's cause for someone who
knows the problem and enjoys working on it to get on a fix.

> On the country/keymap thing, a concrete suggestion: I am not sure it's
> even a good idea to _attempt_ such magic. How about something simpler?
> If you pick any country other than the good ol' U.S.A., we force you
> through the keyboard spoke as the next step, before sending you to the
> hub. It's against the Awesome Hub/Spoke Design, but practically
> speaking, it may be a better option.

And then potentially the network spoke, and that's three things before
you even get to the hub, at which point why did we even bother with this
redesign?

Right now we do have a checkbox on the welcome screen that allows for
setting the keyboard to the default layout, whatever that is.  My hope
is that mapping is good enough for this release.  Somewhere, we have
floating around a mockup for how to add some sort of keyboard selection
to the welcome screen, but that is going to have to wait for F19.

- Chris


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]