Re: Candidacy: Emmanuele Bassi

[Emmanuele Bassi <ebassi gmail com>]

On 2011-05-22 at 02:59, Luca Ferretti wrote:

some of these questions are technical in nature; I do have a technical
opinion in these matters, but it's not part of the Foundation's mandate,
nor it's why I'm running for the board. if I just wanted to have a GNOME
ISO, I'd probably JFDI and punch my way through it — but that would still
not be the reason to run for the board.

my ideas about GNOME OS and how to get there as part of the board are
related to communication with various levels of contributors and users;
to facilitate the creation of infrastructure (both in terms of teams and
applications); and to help define the scope of the goal. choosing the
applications to promote is (already) part of the marketing team mandate;
creating a buildable environment is already part of the release team
mandate; doing QA is already part of the bugsquad team mandate. making
their job easier *is* part of the foundation.

> You said you hope to have an official GNOME OS ISO, so...

we actually had two during the 3.0 alpha and beta, based on two
different distributions.

> Do you think we'll have to create a "gnome iso maker team"?

it should be part of the release process itself, so deferred to the
release-team.

> How do you think we should select extra software (where
> extra software means stuff useful to day to day usage, even
> command line utilities, but not strictly needed to build and run
> GNOME OS)?

the marketing team is already tasked to identify and promote
GNOME-compliant applications on the website. having those applications
available for the users would obviously be part of the process.

> And, related, should we define a policy to provide security
> updates for extra software and non-GNOME software in
> GNOME OS?

this is really a technical question.

security updates make sense if you are not running bleeding edge
software; otherwise they are know as just "updates". the GNOME OS ISO
would always be the latest version of GNOME, as defined by the release
process. should we tweak the release process and make it shorter? should
we adopt a rolling release scheme? these are interesting questions, and
their answer is not for the Foundation to give.

> How should we test all the stuff needed for a first class experience
> (hardware support, drivers, ecc)?

QA is a fundamental issue. right now we rely on "the kindness of
strangers" to test and report bugs. obviously, we'll still need to do
that: we simply cannot test any hardware combination; but we'll also
need some way of determining hardware combinations that work and track
regressions on those.

a small subset of netbooks and laptop models, would already be enough;
when we were developing Moblin for netbooks we tested on three/four
different models of different OEMs. it was obviously easier, because the
hardware matrix was smaller; but it can be bootstrapped in the same way
in GNOME, and improved with time to include other platforms. the
Foundation should even provide facilities for shipping donated hardware
to developers working on low-level elements of the stack.

> Which resources (servers, machines, bandwidtht) will this
> GNOME OS ISO needs?

we do have bandwidth and servers; I cannot tell you how much we'll need
because I haven't run a full analysis. I'm sure that Frederic Peters
will be able to tell you how much bandwidth was consumed by the GNOME
3.0 alpha and beta ISO.

> Do you suggest to "rebase" it on existing distro or create it
> from scratch?

we can "rebase" it on different distributions — depending on the amount of
resources we have. by specifying a set of minimum requirements from the
bottom to the top of the stack, it's not even a case of "rebasing".

as for "starting from scratch": there are build systems that generate
images: SuSE has OBS (which I used as part of my work on Moblin and
MeeGo); Fedora has its own build system; even Debian has its own. the
barrier to create a distribution is pretty low, these days.

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi