Re: Questions for the board election candidates

[Emmanuele Bassi <ebassi gmail com>]

hi;

On 22 May 2012 08:58, Robert Nordan <rpvn robpvn net> wrote:
> Hi all, I have a few questions for the candidates in the upcoming
> election to the board. They are obviously shaped by my interests, but I
> believe that other Foundation members may be interested in the answers
> as well.
>
> 1) "Open Source" or "Free Software"?

aaah, the perennial, philosophical discussion between the Judean's
People Popular Front and the People's Front of Judea. ;-)

why "or"? I'd say "both". there's room for philosophical debate - and
there'll always be room for that, whether we like it or not.
personally, I like to use "free and open source software". thankfully,
I don't have to write it a lot. :-)

> 2) Overhaul of GNOME's git infrastructure

personally, I don't think we need "an overhaul" of our infrastructure.
I classify "an overhaul" in the same scope as "changing the whole
source revision control system", and we clearly had our share of
those.

the main reason why we have a central repository should be obvious to
everyone; GNOME is not a single project with a single code base, so we
cannot have a single authoritative tree, and just release from that.
given the nature of the collection of software that is GNOME, we need
multiple repositories - and we need to grant access to those on
gnome.org.

the main issue is barrier for entry; installing a gitorious instance
on gnome.org would make it "easier" to create an account than the
current process of creating one for git.gnome.org. just as a side
note: one of the reasons why we have a process in place is because
having the write bit on gnome.org allows you to touch every single
repository, so we need to have some check and balances on who gets
one. another one is that a repository on gnome.org usually has a
better visibility and some degree of authoritativeness coming with it,
than a random repository on github.

I somewhat agree: we could install a gitorious instance on gnome.org
to reduce the administrative overhead for creating a Git account to
access a specific set of repositories, e.g. something like
playground.gnome.org, or gitorious.gnome.org, assuming - and this is
what I said multiple times when asked my opinion about  it - that
somebody steps up and helps the sysadmin team with the task of
installing it and potentially maintain it. the role of the Board would
be to facilitate this process: finding (dedicated) hardware, or
bandwidth, in case the current resources are not enough, for instance.
hiring somebody to do it would be a last resort: if nobody is willing
to step up then probably it's not so necessary, after all.

personally, I think that using gitorious.org, or github.com, are
*also* fine choices; moving a repo from there to gnome.org is really
easy (I've done it a couple of times myself). the Accounts team has
done a tremendous job in making the process of getting a Git account
as fast and painless as possible (kudos to them). obviously, lowering
the bar for access to gnome.org is a perfectly fine goal, so who's
going to help out? :-)

> 3) GNOME and Ubuntu
>
> In the recent years there has been a public perception of a schism
> between GNOME and Ubuntu resulting in double work and wasted resources
> on both sides. Do you think that perception is unfounded or not, and how
> do you plan to handle it?

we've gone our separate ways in many regards - though I think we ought
to separate between Ubuntu, the distribution, and Canonical, the
company.

Ubuntu is still using GNOME components, and is shipping GNOME 3; for
this, I'm grateful, and I don't see any issue. many distributions ship
with GNOME, albeit not as a primary environment. that GNOME was chosen
by Ubuntu as their primary environment for these many years was
mutually beneficial, and, again, I'm grateful for that. obviously I'm
disappointed in the change in direction - but I understand the
position and the intent of Canonical (in many ways, it's similar to
ours, albeit with a different implementation), and all I can say is:
good luck, and thanks for all the fish. I think this sentiment is
shared between many GNOME developers.

on the Canonical side, though, I'm less than thrilled. the various
copyright and licensing agreements for Canonical-backed projects
conflicts with my view on contributions and barriers of entry; as I
said during the discussion for the GNOME Copyright Assignment
Guidelines, I barely accept this kind of agreements when they come
from the FSF, under the assumption that the FSF won't really change
that much - but I have many more objections when they involve a
commercial entity. I had to enforce a similar assignment in my day
job, and I tried to get it removed for almost two years - until it was
finally lifted - so I'm really skeptical about them, and the barriers
to contribution that they impose, in exchange for a small measure of
safety for the entity issuing them.

other than that, I think we're still very much collaborating - just
like with any other downstream distribution, when it comes to
packaging, and just like with any other upstream project when it comes
to using libraries or applications as dependencies of GNOME.

> 4) Stance on GNOME forks
>
> Similarly, GNOME 3 has met with some opposing developments like Cinnamon
> and MATE. It is of course the right of dissatisfied users to do what
> they want and fork if they like, but should GNOME ignore them or try to
> find ways to work together with them?

let's start by distinguishing MATE and Cinnamon.

the Cinnamon/Muffin fork was in general possible because of the
infrastructure used by GNOME; it can probably be maintained by a
couple of people part time, assuming that it tracks closely upstream
and assuming some synchronisation point around GNOME release time.
even though I won't be touching it, and I *personally* think some of
the choices are completely and mind-boggingly backwards, I still count
it as a decisive endorsement of the technological choices made by
GNOME. I, and many others, have talked to Clem on IRC, and he has been
engaged in giving feedback on GNOME; in the end, he did what he
perceived as a better move for his own project - and I cannot in any
way begrudge him that: we all do what we think it's best. I'm pretty
sure that, at some point, the process to reintegrate with GNOME will
start, once we smoothed our own rough edges.

as for MATE, I have my issues with it as a sustainable project. I am
sure that the couple of people actually doing all the Sed incantations
to change the name (and email addresses and websites and copyright)
will realize the same soon enough.

forks are a fact of life, in free and open source software; they are
encouraged, as far as I'm concerned. after all, every clone of a Git
repository is a fork, and every patch pushed, or branch merged, is a
fork being reintegrated into the main line. our whole development
model works on the assumption that if I don't like something, I can
change it - and if the maintainer of a project don't like my change,
well: I can convince other people that my repository ought to be the
main line, or I can just give up and use it locally without anyone
being hurt by it.

we should not fight forks, but actively encourage them: people can
experiment and have their own thing, and it'll either get merged
somewhere down the road, or be abandoned, and we'll all learn
something in the process. we should celebrate when a fork gets merged
back (we can get the fat calf, or the nice tofurkey, and have a feast
if you're so inclined). we should also be *very* clear that people
using a fork should not come to GNOME for resolving bugs, unless the
bug exists upstream, and that if you create a fork then you get to
*maintain* it.

hopefully, I replied to your questions in a satisfactory manner; if
not, feel free to ask. :-)

ciao,
 Emmanuele.

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