[oi-dev] Resignation

[Peter]

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

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.

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.

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.

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

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.

I think it's also important to have stable snapshots for users to report bugs against.

I would be prepared to contribute via OI, if this is possible.

The ARM port sounds interesting, ARM64 is a different architecture and doesn't share the 32 bit isa.

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. 

Regards,

Peter.



> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20140913/8107b04c/attachment-0005.html>