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 <[email protected]> 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 > > [email protected] > > http://openindiana.org/mailman/listinfo/oi-dev > > _______________________________________________ > oi-dev mailing list > [email protected] > http://openindiana.org/mailman/listinfo/oi-dev
_______________________________________________ oi-dev mailing list [email protected] http://openindiana.org/mailman/listinfo/oi-dev
