Hi,
It appears your developer has reached the point where he must quit to
get his point accross.
Illumos doesn't have any stable releases and it sounds like developers
are having issues with that.
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.
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.
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).
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.
Also some other ideas, based on observations:
1. Document your governance model, I'm a member of an Apache project,
we have clear rules that assist in resolving differences
1. We have PMC committers and members, we have lazy concensus
and voting, if there's disagreement, we vote after debating
(yes people are passionate), PMC votes are binding, members
votes are non binding (see the apache rules).
2. Also, doers decide.
2. If there are a lot of users, but not many developers, allow users
to make donations against issues, then developers can earn these
donations by completing work.
3. Actively encourage users to donate (Debian has a donation system,
adopt something similar), eg every time someone downloads an ISO,
provide the option to donate.
Regards,
Peter.
On 08/11/14 08:22 PM, Milan Jurik wrote:
>/ Hi,
/>/
/>/ based on the current situation with OI - lack of old OI non-hipster
/>/ branch - and because of bad situation (according my view) of Illumos -
/>/ like stupid ideas to include large chunks of 3rd party code to ON gate
/>/ which makes it unmaintainable (why did Sun and Oracle invest so much to
/>/ remove OpenSSL, SunSSH and ksh from ON gate? See how bad is ksh in
/>/ Illumos and how old is Illumos SSH) I have to finalize my decision about
/>/ my participation. Illumos and its distros are not for me anymore.
/I think idea behind that is to have current SSH for illumos, and later
to remove it from illumos.
But It is yet to be determined are there SPARC hardware crypto support
inside new solution (that is present in SunSSH), because that would be
very short-sighted if it is not.
GDA even tried to remove UltraSPARC T1/T2 support (?). illumos is
tailored by few large companies wishes , that actually pay developers,
but it is always possible to contribute.
>/ opensolaris.cz will be up for some time but no more updates to JDS and
/>/ SFE. Do not hestitate to contact me in private if you think I still know
/>/ something but I will not spend more time on the lists.
/>/ If anybody is interested in some older bits then:
/>/
/>/ http://www.opensolaris.cz/builds/illumos-wpa-enterprise/webrev/
/>/ http://www.opensolaris.cz/builds/tnf/webrev/
/>/ http://www.opensolaris.cz/builds/ext2-merge/webrev/
/That sounds a bit interesting, since Hipster is much more BSD-style
development by few commiters and yet I understand you left for BSD.
Hipster broke code consolidations some time ago and without actual
numbered versions that are pushed, it is hard to test and debug many new
bugs. (And without resurrected 'updatemanager' to update regularly)
There is large disproportion between number of people wanting just to
install and use OI and illumos distributions and those that want to
maintain and work on it.
Current situation in OI is tailored for small number of hands active and
it is extracting maximum results from current situation, but that would
be changing (together with dev process) as more people are involved again.
Maybe good way to start further is Install OI from 151a3 (to get Zpool
28 by default for S11 compatibility) and upgrade to 151a8 or install
from 151a8 directly. And then upgrade from it to Hipster
(/hipster-2014.1) and to see what could be done to upgrading individual
packages of interest for.
Again, breaking consolidations like JDS is not good but it requires
people in TEAMS working together on same project, so more people involved.
We will all love to se newer releases in /dev but that needs making
releases out of Hipster that goes in line with continuing from latest /dev.
Maybe general problem is illumos itself not having numbered releases to
have some basis for maintaining patches for some stable version, and
that reflect distributions in a bad way.
--
Nikola M.
_______________________________________________
oi-dev mailing list
[email protected]
http://openindiana.org/mailman/listinfo/oi-dev
