[oi-dev] Resignation

Sat Sep 13 08:00:32 UTC 2014

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