[oi-dev] Resignation

Sat Sep 13 12:29:35 UTC 2014

Blame is as useful as ignorance and accusation.

Perhaps this is the right development model for this project.

I genuinely hope that OI and Illumos succeed.

With regards to sparc, as much as I like the modular Solaris kernel, Dtrace etc, it makes more sense on this occassion to investigate Gentoo as it is a free project with active sparc developers.

I do have a number of spare disks and sparc hardware, so can help out if things improve on the sparc front.

Thank you for your time.

Regards,

Peter.

----- Original message -----
> Hello.
>
> I'd like to say that upstream illumos-gate is stable and is the least
> our problem.
> We've seen only 3 breakages in a year:
> 1) DTrace change which required additional patching for some software
> (IIRC mysql, mariadb, percona and perl DTrace providers were affected)
> 2) One change in ipv6 handling which broke VNC server (was fixed almost
> immediately after discovering)
> 3) Several changes which broke packaging (were fixed soon enough, in day
> or two after discovering)
> And one change which could break grub on OI was fixed during review
> phase.
>
> There were also some changes removing software (like ntfsprogs) which
> required us to add it to oi-userland.
> Additionally we had to add one (!) simple patch to illumos-gate to allow
> building with Perl versions > 5.10.
>
> So, I don't say that interaction with illumos-gate dev team is a
> problem.
> All the times illumos devs were extremely friendly and I think that
> attempts to blame them are just FUD and provocations.
>
> As for real problems...
> If you mention SPARC - yes, it is slowly becoming second class citizen.
> But as far as I know, all SPARC-related patches coming from Igor
> Kozhukhov or Gary Mils were accepted.
> The reason for this state is that SPARC is some kind of sacred cow for
> illumos.
> Noone wants to drop SPARC support (I think most reasons for this are
> religious), but only several men
> really do something to keep it alive.
> I'm personally one of those who don't care about SPARC, so I wouldn't
> say that it's the main OI problem.
>
> The main problem is the lack of developers. The other are coming from
> this one.
> I'd say that a lot of outdated software or software which can't be
> easily rebuilt is a problem.
> I think that software coming from JDS and XNV consolidations which is
> still out of oi-userland is a problem.
> I think that binary blobs (e.g. /usr/bin/make or motif) which can't be
> easily rebuilt is a problem.
> I'd say that lack of software usual for FreeBSD or Linux user (e.g.,
> postfix, smartmontools, hhvm on server side,
> fresh python, perl, ruby versions for developers or audio and video
> codecs, virtualbox, wine for desktop users)
> is a problem.
> ---
> System Administrator of Southern Federal University Computer Center
>
> Peter писал 13.09.2014 11:23:
> > ----- 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
> >
> >
> > _______________________________________________
> > oi-dev mailing list
> > oi-dev at openindiana.org
> > http://openindiana.org/mailman/listinfo/oi-dev
>
> _______________________________________________
> oi-dev mailing list
> oi-dev at openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev

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