[oi-dev] Resignation

[Joshua M. Clulow]

On 13 September 2014 00:23, Peter <jini at zeus.net.au> wrote:
> Building and testing only on the developers computer before integration
> isn't sufficient to be considered stable and those who would contribute,
> don't have the resources to test widely enough to satisfy the stable
> contribution only model.

It is actually sufficient for many changes.  For example: if you are
modifying the "grep" utility, and you have written some tests to show
that your change works as you expect, and you have run any existing
tests to show that it still works as others expect, then it should
very likely be fine.  Coupled with review from at least one qualified
person via direct mail, or on the developers@ list or IRC, you can be
relatively sure that the vast majority of changes going into the gate
actually work basically everywhere.

> 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.

It absolutely does not.  If you want to have a private branch
someplace, you are welcome to.  You can post it on github, or
bitbucket, or your own server, or just keep it on your local machine.
If you want design or code review, or broader testing, you're welcome
to publish changes (sources, diffs, webrevs, even binaries) in
whatever form is convenient for your reviewers and testers.  There's
intentionally very little process right up until the point where you
want your change to go into illumos-gate -- at that point, you must
simply satisfy an advocate that you have achieved appropriate review
and testing.  The advocates are (busy) human beings -- they respect a
fully complete request to integrate when they see one, but they're
capable of (and generally willing to) explain what a contributor needs
to do to be accepted.

The illumos-gate consolidation contains the kernel and the most
fundamental libraries and programs that make up the operating system.
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.

> 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.

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.

> If this is the Illumos development model, the community needs to find a way
> of working with it.

The way is: [1] talk to people and then [2] do work.  We believe in
rough consensus and running code.

> It sounds like Joyent has an internal experimental branch and it sounds like
> that's what OI needs in order to enable community based developers to
> participate similarly to Joyent developers.

We don't have any secret internal branches that I am aware of.  We
generally all work on the "master" branch of illumos-joyent; hosted on
github.  We cut periodic releases of our broader product set (which
include a bootable illumos platform image) once a fortnight.
Critically, we can also create ad hoc "master" releases _at any time_
if we need a bug fix or new feature, so "master" must _always_ be
production ready.  We can merge "illumos-gate" into our fork every day
because it _also_ has the property of being production ready at all
times.

> 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.

> 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.


Cheers.

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