[oi-dev] Time for Divorce from Oracle (was Re: pkg5 Linked Images)

Deano deano at rattie.demon.co.uk
Mon May 30 21:14:57 UTC 2011


+INFINITY+1

Whilst we are being all revolutionary. Whats our actual name?

Open Indiana, OpenIndiana, Openindiana, Project OpenIndiana, The OpenIndiana
Project, ...

Think I've seen all a one point or another, personally I like OpenIndiana.
Bad English but I like.

Deano

-----Original Message-----
From: Alasdair Lumsden [mailto:alasdairrr at gmail.com] 
Sent: 30 May 2011 21:56
To: OpenIndiana Developer mailing list
Subject: Re: [oi-dev] Time for Divorce from Oracle (was Re: pkg5 Linked
Images)

Hi Ken,

On 30 May 2011, at 19:04, Ken Gunderson wrote:
<snip>
> Not having  time to follow your links, but on the subject of Oracle I
> have been meaning to comment for sometime.  I think it's long past due
> for IllumOS and OI to accept that we need a clean divorce from Oracle
> and that this masquerade of a trial separation is in reality fooling
> nobody but ourselves.  Time to get over it and on with our lives.
> Depending on anything from Oracle leaves us not only vulnerable to the
> whims of the powers that be, but also relegates us to second class
> citizenry.

Absolutely.. this is the conclusion that I think everyone has come to. It's
interesting you raised this now, I was planning on firing off an email
tonight on this very topic.

Officially, we should fork. We should update the FAQ and any other docs to
reflect this, once we've fleshed out exactly what we mean.

If we don't fork, we're following instead of leading, and this (as you
pointed out) means we're just a second class citizen in the Solaris
ecosphere. If we want to succeed, we have to innovate, and to innovate, we
have to attract top developers. The only way to do this is to lead, and
allow people to contribute without fear of being trampled on by upstream.

Forking will also help with the way things are organised. The way
OpenSolaris was developed within Sun, which consisted of different teams
around the globe working on different consolidations, with different build
systems (some of which are pretty horrid to work with), might work for a
large commercial company with paid developers, but it doesn't work for an
open source project like ours. It's needlessly complex, and means there's a
really high barrier of entry for new developers. People can't easily
download the source, get hacking, and install the changes they've made, and
get those changes easily integrated.

We need to overhaul the way things are structured into a single unified
build system that is natively IPS based. There has been a lot of interest in
using the "userland" consolidation to do this, and collapsing the other
consolidations into it. For example pkg5, slim_source, g11n etc can just
become components of userland. It should be possible for people to check out
the source, make changes, and type "cd foo ; make publish ; pkg install
foo". Then if they want to build the ISO, do something like "make live-iso"
or "make text-iso". This build system should be contained in a single
mercurial repo and branched at each release, so security and bug fixes can
be kept easily in it. Bye bye mercurial patch queues.

This wouldn't just help new developers, it would help *everyone*, especially
the existing core devs. It would massively speed up development of the OS,
and the release engineering process. It would also make keeping the OS up to
date with bug and security fixes for the stable branch, because that would
be a branch we push updates to.

We should still leverage the Oracle upstream to import changesets that are
of interest to us. But we shouldn't manage our contributions as a set of
patches on top.

This is what we should be aiming at for the next build after oi_151. I'm due
to send out another email related to the public IPS repos and the version
numbers used within.

Cheers,

Alasdair


_______________________________________________
oi-dev mailing list
oi-dev at openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev





More information about the oi-dev mailing list