> 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 _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
