On Monday, December 06, 2010 02:52:17 am Adam Williamson wrote: > 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). Some combination of b) and c) should work - be as higher level QA - if someone is using Fedora brand - we have to be sure it's using Fedora brand in that way we can be proud of it ;-) But not in the way how Firefox enforces this rule :) c) needs again some coordination - someone has to poke folks with built image etc. (it was a problem before Validation tests - it was somehow releases and everyone was prying it works). > > 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? See my reply in this thread with Fedora Platform idea - I think it's the only way how to achieve this (although it doesn't solve independent, not independent (sub)projects etc.). It's wonderful time now for Linux based solutions! Nearly all set-top boxes are Linux based (except the cheapest ones), ever fridges are now Linux-powered. I know - this is more embedded world but it's a huge market for us -> more contributors. Jaroslav > 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! -- Jaroslav ÅeznÃk <jreznik@xxxxxxxxxx> Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 602 797 774 Red Hat, Inc. http://cz.redhat.com/ _______________________________________________ advisory-board mailing list advisory-board@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/advisory-board
