On 09/13/14 09:58 AM, Joshua M. Clulow wrote:
On 13 September 2014 00:23, Peter <[email protected]> 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.
_______________________________________________
oi-dev mailing list
[email protected]
http://openindiana.org/mailman/listinfo/oi-dev
