On Wed, 2010-12-01 at 11:31 -0800, Adam Williamson wrote: > Hi, Board! I'm not going to reply to anyone else's specific reply here, as the discussion branched and twisted a lot. :) So, three general things in reply: 1) the point that we currently ship spins with no idea whether they work or not, and do in fact sometimes (often?) ship completely broken spins, is an important one. There's actually an argument that this is OK, and that should be considered, though it's counter-intuitive. But it's important to realize that this is entirely a part of the present system and if we don't want that to happen we do need to change the system. Right now, we would never ship a broken Desktop spin, we would almost certainly never ship a broken KDE spin, and it's quite unlikely, since F14, that we would ship a broken LXDE or Xfce spin. Beyond that, all bets are off. There is currently no official testing coverage for the spins beyond those four (I'm trying to cover Sugar, but we didn't quite manage it for F14). As a project, we have no real clue whether they work at all when we ship and to some degree publicise them. The current policy, as Jesse described it, is that we build them, we publish them, and if we find out they're broken, we pull them. That's it. There's various ways we can handle this: a) declare it not a problem, as is the current policy b) require QA to do some minimal 'does it work?' testing of all spins, and don't publish ones that are totally broken c) require the SIG (or whatever) that owns each spin to do the basic testing and sign off on the spin before release: if they don't sign off on the spin, it's not published. QA and releng can help facilitate this process if required (just by providing test builds and pointers for testing). those are the ones I can think of. 2) I think there is a significant element to the wide question that Greg and Mairin were discussing which may not yet have been addressed: we have to take into account the changing nature of the whole world we operate in. Perhaps three or four years ago, the question was only GNOME, KDE, Xfce, LXDE: they're four different approaches to essentially the same problem. They have different philosophies and each may think it's right and the others aren't, but they're all more or less trying to answer the same question. If you throw Sugar and Meego, especially, into the pot, things become much less clear. Sugar and Meego are fundamentally not trying to answer the same questions as GNOME, KDE, Xfce and LXDE. Implicit in this is that it's harder to say 'if we prioritize and focus on a single desktop we can provide a more refined answer to everyone's needs; they may think one of the other desktops is a better answer, but at least our nice focused streamlined solution is *an* answer'. That's really pretty unconvincing when it comes to the *different* questions Sugar and Meego are trying to answer. I think it'd be extremely difficult to sell someone on GNOME being a good functional learning environment, or a good interface for a tablet or cellphone (yes, we don't ship the Meego cellphone UX yet, but I know some of us would *like* to). So here's the new factor: it is now at least theoretically possible for the Fedora project to provide environments that are fundamentally different from GNOME, and are aimed at answering completely different needs, which we realistically cannot answer within the context of our single preferred desktop/spin/build/whatever you want to call it. To do this we have to take a wider conception of the Fedora project. Some people within the project are already doing this, which is why we have Sugar and Meego packaged (and as spins) at all. Do we embrace that wider function and start to think of Fedora as a broad-based platform on which we can build and provide *different* user experiences? Or do we explicitly say that's too high a goal, Fedora should still focus on providing a traditional desktop environment first and foremost, and markedly different environments are a completely secondary and optional priority, and should probably be done at 'arm's length', as semi-independent projects or child distros, as SoaS used to be before it became an official spin? 3), and possibly somewhat in contradiction to 2) :), I do hope we can put at least some focus on simply solving the active practical issues here. I know there are interesting wide theoretical discussions to be had - like 2)! - but we should at least look in the short-term at smoothing out our story specifically about spins, resolving the practical inconsistencies I identified in my initial post, at least in the short term. Thanks for all the discussion so far! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net _______________________________________________ advisory-board mailing list advisory-board@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/advisory-board