[oi-dev] Resignation

[Nikola M.]

On 09/13/14 09:58 AM, Joshua M. Clulow wrote:
> On 13 September 2014 00:23, Peter <jini at zeus.net.au> wrote:
>> Current policy also denies would be community developers the benefits of an
>> experimental branch; peer review and wider testing. There may be exceptional
>> developers who's code is perfect, but I am not one of them.
> ...
> If we were to have a public "experimental" branch, with less (or no)
> restrictions on what could be committed to it, it would clearly break
> from time to time.  Folks would (rightfully) be reluctant to use it
> for anything important, because it might break; it will thus not
> receive the wider testing and review you are espousing.  This is
> called the Quality Death Spiral -- removing the hard requirement for
> quality ensures that quality will deteriorate faster and faster over
> time.
And illumos not having actual releases, does not help distributions, but 
exactly push them in state you described.
And at least push maintaining stable releases to many separate 
distributions, but maintaining it at one place, illumos.
I think that maintaining "continuously stable" illumos is more folks 
tale then it could be real.
- How can illumos achieve any kind of BINARY compatibility (that Solaris 
was known for)
between RELEASES, when it does not have releases?... and does not have 
centralized support for maintaining them?

And on OI distribution level I also remember the time when I was using 
Opensolaris /dev releases daily and actually I witnessed many bugs that 
went into releases, but were quickly fixed in next /dev after few weeks, 
_precisely_ because people had NUMBERED versions to reference to and 
because of wider testing of the whole system. Opensolaris /dev was very 
much useful, actually the same way OI /dev is in the same way.
So there is nothing like "quality of death spiral" with wider use for 
testing on distribution level and enforcing illumos kind of development 
philosophy on distribution level could actually lead to quality death 
spiral.

I understand that "continuous integration" on distribution level is 
disastrous for wider audience, like you concluded, but having 
distribution RELEASES is beneficiary and is a must.
>
>> For the rest of us, a second set of eyes helps to develop well considered
>> api's and better quality code, and this includes a skunk build and wider
>> testing.
> Language like this is not helpful -- there are _not_ two classes of
> contributor.  Every single contributor, regardless of affiliation, is
> empowered (and expected) to write changes, seek review, test their
> software (or arrange others to test it), and submit requests for
> integration.
Simply because distributions not backed by large companies does not have 
resources to maintain separate "stable" illumos (but could contribute of 
course).

That is what makes differentiation between "big" illumos contributors 
and small ones visible,
without Versioned releases that are centrally maintained - it suits big 
players, new or small ones are even discouraged to maintain their own 
forked illumoses.
OI Hipster followed recommendations for "reference distribution" but 
that gave us nothing production ready at all.

> If code review (a second set of eyes) helps you, that's great -- it
> helps me too!  And, I definitely _build_ the software before I put it
> back.  I also definitely seek wider testing if I feel that I am unable
> to test some reasonable combinations of hardware and software by
> myself.
I now remembered to ask one question:
Is KVM and per-zone disk throttling (and other things maybe)
finally integrated in mainline illumos? (Or at least pushed to illumos).
And if it is not, why not? Why keeping important things like that out of 
illumos, maybe because it would require putting release numbers in 
illumos, for big changes?
>> I think it's also important to have stable snapshots for users to report
>> bugs against.
> It may be important to have stable snapshots of _distributions_, which
> are what users actually install and thus report bugs against.  If you
> report a bug against SmartOS, we at Joyent must first determine if
> it's a bug in software we have modified or added to the system, or
> code from upstream.  It is essentially mandatory that users can tell
> us the datestamp from the platform image they are running in order for
> us to help them.   The same generally applies to OmniOS and
> OpenIndiana, with whatever versioning schemes they are using for their
> shipped binary components.
Ok, that supports reviving OI /dev and having numbered versions in 
Hipster updates.
But not having stable releases of illumos is binary compatibility is 
bummer for distributions.
>
>> So SPARC is presently unmaintained.
>>
>> While I couldn't commit to maintaining it, as it is a significant
>> undertaking, I could run tests and help debugging and contributing some
>> improvements.
> Yes, it _is_ a significant undertaking.  That nobody has enough time
> or resources to step up and commit to being responsible for the whole
> thing, with or without help from folks like yourself, is really the
> reason that it's unmaintained.  I'm not trying to make out like SPARC
> is some kind of evil, just that there won't likely ever be enough
> users and engineers to feed and water it.
I think that few people wanting to contribute to SPARC were publicly 
told to go away,
that general illumos climate toward SPARC is hostile (not on agenda for 
big companies using illumos)
and that components that use SPARC specific functions (crypto) are just 
in a process of removal and kill, because of exactly problem with 
telling people wanting to have SPARC support to - go away.
Definitely, companies with contracts with , say Intel, would not have 
interest of maintaining code for other hardware platforms.
But that pushes illumos to niche platform again , lke in a days, when 
Solaris was made especially for SPARC, without x86 support. Let's not do 
the same mistake again.