<div dir="ltr"><div>The issue of governance has been talked about before, so I'll just summarize the decisions the Illumos community reached.<br><br></div>Governance causes way more problems than it solves. For example, it adds a political aspect to the community, creating clear winners and losers. This leads to rivalry, factions, and the like. This can cause schisms in the community. I used to be a Gentoo user years ago, and I watched the community tear itself apart over petty politics. For example, technological decisions were on the basis of personal egos, feuds, and certain devs' personalismo. As opposed to technical merits and objective measurements. All of this happened because the founder of Gentoo, left the project and left a governing-board in his place. The Illumos community believes --- and please correct me if I'm wrong --- that those who write the code have the power to decide, to disagree, and so on. Those who are merely consumers of the code don't get much say in development decisions. Hence, there is no need for governance. Code rules.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Sep 7, 2014 at 2:24 AM, Peter Firmstone <span dir="ltr"><<a href="mailto:jini@zeus.net.au" target="_blank">jini@zeus.net.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
It appears your developer has reached the point where he must quit to get his point accross.<br>
<br>
Illumos doesn't have any stable releases and it sounds like developers are having issues with that.<br>
<br>
Also it sounds like experimental features are being introduced into the Illumos kernel and these components also sound like they belong in a distribution rather than the kernel.<br>
<br>
If Illumos isn't prepared to listen, maintain a stable kernel version here on OpenIndiana, give it a version, track the changes and make it available to other distributions, treat Illumos like experimental code, contribute fixes back to Illumos.<br>
<br>
Again: Create kernel stable releases, leave out the experimental stuff (if it's not part of the kernel and can be provided as an optional package, leave it out).<br>
<br>
Eventually Illumos will come around, if not, only integrate what makes sense and ignore what doesn't and continue to contribute fixes upstream.  It's not worth loosing developers over external project issues.<br>
<br>
Also some other ideas, based on observations:<br>
<br>
  1. Document your governance model, I'm a member of an Apache project,<br>
     we have clear rules that assist in resolving differences<br>
        1. We have PMC committers and members, we have lazy concensus<br>
           and voting, if there's disagreement, we vote after debating<br>
           (yes people are passionate), PMC votes are binding, members<br>
           votes are non binding (see the apache rules).<br>
        2. Also, doers decide.<br>
  2. If there are a lot of users, but not many developers, allow users<br>
     to make donations against issues, then developers can earn these<br>
     donations by completing work.<br>
  3. Actively encourage users to donate (Debian has a donation system,<br>
     adopt something similar), eg every time someone downloads an ISO,<br>
     provide the option to donate.<br>
<br>
Regards,<br>
<br>
Peter.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 08/11/14 08:22 PM, Milan Jurik wrote:<br>
>/  Hi,<br>
/>/<br>
/>/  based on the current situation with OI - lack of old OI non-hipster<br>
/>/  branch - and because of bad situation (according my view) of Illumos -<br>
/>/  like stupid ideas to include large chunks of 3rd party code to ON gate<br>
/>/  which makes it unmaintainable (why did Sun and Oracle invest so much to<br>
/>/  remove OpenSSL, SunSSH and ksh from ON gate? See how bad is ksh in<br>
/>/  Illumos and how old is Illumos SSH) I have to finalize my decision about<br>
/>/  my participation. Illumos and its distros are not for me anymore.<br>
/I think idea behind that is to have current SSH for illumos, and later<br>
to remove it from illumos.<br>
But It is yet to be determined are there SPARC hardware crypto support<br>
inside new solution (that is present in SunSSH), because that would be<br>
very short-sighted if it is not.<br>
GDA even tried to remove UltraSPARC T1/T2 support (?). illumos is<br>
tailored by few large companies wishes , that actually pay developers,<br>
but it is always possible to contribute.<br>
>/  <a href="http://opensolaris.cz" target="_blank">opensolaris.cz</a> will be up for some time but no more updates to JDS and<br>
/>/  SFE. Do not hestitate to contact me in private if you think I still know<br>
/>/  something but I will not spend more time on the lists.<br>
/>/  If anybody is interested in some older bits then:<br>
/>/<br>
/>/  <a href="http://www.opensolaris.cz/builds/illumos-wpa-enterprise/webrev/" target="_blank">http://www.opensolaris.cz/<u></u>builds/illumos-wpa-enterprise/<u></u>webrev/</a><br>
/>/  <a href="http://www.opensolaris.cz/builds/tnf/webrev/" target="_blank">http://www.opensolaris.cz/<u></u>builds/tnf/webrev/</a><br>
/>/  <a href="http://www.opensolaris.cz/builds/ext2-merge/webrev/" target="_blank">http://www.opensolaris.cz/<u></u>builds/ext2-merge/webrev/</a><br>
/That sounds a bit interesting, since Hipster is much more BSD-style<br>
development by few commiters and yet I understand you left for BSD.<br>
Hipster broke code consolidations some time ago and without actual<br>
numbered versions that are pushed, it is hard to test and debug many new<br>
bugs. (And without resurrected 'updatemanager' to update regularly)<br>
<br>
There is large disproportion between number of people wanting just to<br>
install and use OI and illumos distributions and those that want to<br>
maintain and work on it.<br>
Current situation in OI is tailored for small number of hands active and<br>
it is extracting maximum results from current situation, but that would<br>
be changing (together with dev process) as more people are involved again.<br>
<br>
Maybe good way to start further is Install OI from 151a3 (to get Zpool<br>
28 by default for S11 compatibility) and upgrade to 151a8 or install<br>
from 151a8 directly. And then upgrade from it to Hipster<br>
(/hipster-2014.1) and to see what could be done to upgrading individual<br>
packages of interest for.<br>
<br>
Again, breaking consolidations like JDS is not good but it requires<br>
people in TEAMS working together on same project, so more people involved.<br>
We will all love to se newer releases in /dev but that needs making<br>
releases out of Hipster that goes in line with continuing from latest /dev.<br>
<br>
Maybe general problem is illumos itself not having numbered releases to<br>
have some basis for maintaining patches for some stable version, and<br>
that reflect distributions in a bad way.<br>
<br>
--<br>
<br>
Nikola M.<br>
</blockquote>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
oi-dev mailing list<br>
<a href="mailto:oi-dev@openindiana.org" target="_blank">oi-dev@openindiana.org</a><br>
<a href="http://openindiana.org/mailman/listinfo/oi-dev" target="_blank">http://openindiana.org/<u></u>mailman/listinfo/oi-dev</a><br>
</blockquote></div><br></div>