Strong leadership and a very very large investment in man-hours. The problem with OI is the build and assembly of it, i.e. the "release engineering". It's very difficult and very tedious as-is. Nobody wants to do it. Well, almost nobody - Jon Tibble has taken this on, but given the amount of work involved, I am not surprised progress has been slow.
The whole way the OS is built needs refactoring. At the moment there are a large number of different build systems, "consolidations" in Sun parlance, such as JDS (desktop), SFW (Sun Freeware), userland-gate, pkg5, xnv, etc etc. This needs to all be reduced to one single easy to use build system (ideally). I attempted to do this with oi-build, which took the best build system (userland-gate) and automated building with Jenkins (a continuous build system). But oi-build got politicised, Nexenta wanted to collaborate with OI on the userland, so oi-build became illumos-userland, which went nowhere, and ended up pissing everyone off to the point people lost interest and the whole thing died. Then I resigned. I don't know what Jon Tibble's plans are, I think the last time I spoke about it he favoured a slow movement of things into oi-build over time. Perhaps that's a good place for contributors to get started. I imagine people do want to contribute, and would, if they had an easy way to do so, with documentation and guidance and a helping hand. On Mon, Apr 15, 2013 at 8:21 PM, Jim Klimov <[email protected]> wrote: > On 2013-04-15 20:56, Jose-Marcio Martins da Cruz wrote: > > Alasdair Lumsden wrote: >> >>> OpenIndiana was started as an open source community developed distro >>> similar to Debian, but due to a >>> lack of interest there are only a few developers working on it part >>> time, so updates are slow, and >>> limited in scope due to the size of the project. >>> >> >> Does this means that you think OpenIndiana is dead ? If yes, how to >> avoid it ? >> > > That is a two-fold question. > > If it is "how to avoid OI" - the answer is, alas, trivial ;) > > If it is "how to avoid DEATH of OI" - commit fixes and RFE/bug reports. > One frequently requested vector is regular and frequent integration of > updated versions of common open-sourced software and particularly of > security patches (maybe porting of those and feeding back upstream, if > existing bugfixes are not verbatim applicable on Solaris/illumos/OI). > > Test the new solutions provided by upstream code repositories that they > don't break OI and provide the feedback that these can be pulled into OI > (or if they should be avoided because of this and that, which needs to > be fixed). > > On the organizational side, build an up-to-date information (or validate > existing one) about constructing the distro, including rebuilds of the > kernel, userspace and 3rd-party (SFE) software. And get some process in > place to more regularly roll out package updates and live-media distro > images. After all, OI is largely just one of many methods to package > common software, which other distros fulfil with their methods. There > is likely some code unique to OI (such as, perhaps, the installer and > its default behavior, or the GUI-related things mostly absent from the > server-oriented distros), but much of the kernel and updated utilities > RTI'd recently are common with the upstreams (illumos-gate et al). > > Here's my thoughts on this, > //Jim Klimov > > > ______________________________**_________________ > oi-dev mailing list > [email protected] > http://openindiana.org/**mailman/listinfo/oi-dev<http://openindiana.org/mailman/listinfo/oi-dev> > -- Alasdair Lumsden http://www.everycity.co.uk EveryCity Managed Hosting Studio 18 Bluelion Place 237 Long Lane, London, SE1 4PU general: 020 7183 2800 support: 020 7183 2801 email: [email protected] Every City Limited Registered in England and Wales, No. 5689474 Registered Office: Roper Yard, Roper Road, Canterbury, CT2 7EX
_______________________________________________ oi-dev mailing list [email protected] http://openindiana.org/mailman/listinfo/oi-dev
