[oi-dev] Resignation

[Joshua M. Clulow]

On 12 September 2014 17:28, Peter <jini at zeus.net.au> wrote:
> That's rich, a project with no stable release baseline to measure binary
> compatibility against won't accept patches unless ...

Actually, our stated goal of "FCS quality all the time" means that we
intend to treat _every commit_ in the gate as a stable release.
Things are only integrated when they work, and once they're
integrated, documented, and people are able to use them, we intend to
keep supporting them compatibly.

Accidents happen; negligence cannot.  We may not be perfect, but we
_strive_ to be, and to fix bugs (or revert integrated changes) as
quickly as is possible so that the software remains unbroken.

> The logical solution is to maintain a stable kernel release version at OI,
> then use that as a baseline for patches and submit patches upstream to
> Illumos from OI rather than from individual developers.

Working on your own distribution-specific fork of illumos-gate is a
reasonable idea -- it's the model we use for SmartOS at Joyent.  If
your intent is to avoid work creeping up on you, I would recommend
that you merge changes into your fork early, and often.  At Joyent, we
merge into the SmartOS fork, illumos-joyent, on most business days.  I
can't recall a time when we experienced serious difficulty from
changes we received through these syncs.  We also try to minimise our
diff from upstream periodically by submitting chunks of our work for
integration into illumos-gate.

> That will put your patches on an equal footing as those with commercial
> interests.

No, the _only_ thing that will put your patches on equal footing with
the commercial interests is to do the software engineering required to
produce quality, tested changes.  There are not different sets of
rules for different contributors -- the same attention to quality,
testing, sensible architecture, etc, is expected from all
contributors.

> I'd ignore the FUD about legacy platforms, projects that support multiple
> architectures are more stable for it.

I whole-heartedly agree that operating systems that run on more than
one architecture are less likely to see particular classes of bugs
that are hidden by some architecture-specific implementation detail;
e.g. byte ordering, different core system hardware drivers, etc.
Unfortunately, if there are no _active_ OS engineers using and working
on a particular architecture, it will absolutely rot over time;
eventually becoming an obstruction to important changes where those
changes require architecture-specific work.

> With regard to sparc, there are a number of current chip manufacturers, Aeroflex, Fujitsu, Oracle, FeiTeng. How hard would it be to support sparc v8? What about ARM64?

Robert Mustacchi, myself, and a few others, have been investigating
(and in Robert's case, working on) an ARM port of the OS.  It's a lot
of work -- work which is entirely uninteresting to our employer, so
it's a spare time project.   I would love to see it completed, and
hopefully we will get there in time.

> It's clear that Illumos isn't the right place for me to contribute directly, but the whole community will benefit if I and others like me can contribute via OI.

Why is that?  If you want to procure and operate SPARC hardware, to
fix build issues as they arise, and to write SPARC-specific code for
changes that require it, why not do it in illumos?  If you (and others
like you) do not step up to maintain the SPARC bits, then they truly
are dead weight and need to be removed.

-- 
Joshua M. Clulow
UNIX Admin/Developer
http://blog.sysmgr.org