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

Hernan Saltiel hsaltiel at gmail.com
Mon May 30 23:01:51 UTC 2011


IMHO: eternal and happy +1!!!!
Best regards,

HeCSa.



On 5/30/11, Alasdair Lumsden <alasdairrr at gmail.com> wrote:
> Hi Ken,
>
> On 30 May 2011, at 22:32, Ken Gunderson wrote:
> <snip>
>> Your MUA doesn't wrap lines at any reasonable length, which makes
>> replying inline more challenging than it should be but a few thoughts:
>
> Sorry. I'm using Apple mail. I looked in the preferences but nothing jumped
> out, if anyone knows how to adjust this let me know. I'm going to switch to
> Thunderbird on my macbook when I can find the time, which should hopefully
> knock the problem on the head.
>
> <snip>
>>> 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.
>>
>> I think more than a few saw this writing on the wall long, long ago but
>> were shot down as Oracle bashers so left and went back to Linux.  I'm
>> probably one of few coming from non Solaris background still hanging
>> around??
>
> I'd try not to let any of the trolls on the mailing lists influence which OS
> you use; the OI devs care about OI and if you like the product and where its
> going then please do stick around! And of course if you don't like where
> things are going, you can get involved or give feedback.
>
>>> 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.
>>
>> +1
>>
>>> 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.
>>
>> Yes, OI doesn't have the $ and developer resources that Oracle has, but
>> still in my mind has the much more potential than Solaris because in
>> order to fuel those corporate resources Oracle only wants to sell to
>> high end, top echelon big enterprises.  This strategy may well make lots
>> of money for Oracle but in so doing Solaris will still end up being
>> somewhat of niche platform due to being priced out of reach of the
>> typical budget conscious enterprise.  Meanwhile, OI could well capture
>> this "market".  Attracting developers will be key. And...
>
> Absolutely.
>
>>> 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.
>>
>> As you rightly point out - pretty much a nightmare state of affairs,
>> even for experienced developers, as some feedback I've gotten goes.
>> Never mind someone who may be somewhat technical but not a coder, e.g.
>> sysadmins coming from other platforms.
>
> Yup!
>
>>> 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.
>>
>> Absolutely.  Although I'm not so sure IPS is necessarily the way to go.
>> One advantage is that it is here now.  But otoh, there are other mature
>> systems out there that might be leverages, e.g. pkg_src from NetBSD or
>> apt from Debian.  The latter would be good from making things more
>> familiar for Linux users "goal" that some advocate.
>
> Without starting a massive packaging debate, IPS is one of the main
> non-negotiable points! It's exceptionally good and one of the foundations of
> the OS. There's no way we could switch now. There's a lot of FUD out there
> about IPS but I hope over time people will come to realise just how good it
> is.
>
>>> 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.
>>
>> Definitely in serious need of overhaul.
>>
>>> 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.
>>
>> And herein lies the biggest key paradigm shift.
>
> Yup. It's a scary one - divorcing from Oracle will make pulling in their
> changes much harder. But conversely it will set us on our own course.
>
>>> 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.
>>
>> Rock on, Alasdair!!
>
> :D
>
>
> _______________________________________________
> oi-dev mailing list
> oi-dev at openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev
>

-- 
Sent from my mobile device

HeCSa




More information about the oi-dev mailing list