[oi-dev] Resignation

Sat Sep 13 02:16:36 UTC 2014

Stability issues only appear to exist with one upstream project.

Maintain a stable branch for OI and diff and review upstream changes, that'll stabilise OI's build.  Report any breakages to the upstream maintainers and don't merge changes that cause breakage.

Where does this community want to go?

Forget about desktop, server etc, I might have a server that needs DRI to support GPGPU, while you might have a desktop that needs DRI to support 3D graphics.

Get back to basics:
* Relaibility
* Stability
* Compatibility
* Hardware support

Obviously standards and well documented hardware, or well supported by free software is easier to support.

I've noticed with sparc there's a lot legacy closed hardware and drivers etc.

It's clear the Xorg, IPS and such are the future, but this shouldn't prevent others from bundling OI with legacy binary drivers and other stuff and OI shouldn't deliberately break compatibility unless absolutely necessary.  Debian used to have a non-fee section (don't know if this is still the case) but that could work here too.

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?

Going forward longer term, if people want 3D graphics on sparc, they'll need to work out how to utilise PC hardware.

I've been looking into 8086 real mode emulation and whether it can be compiled into fcode, allowing PC cards to be flashed to support OpenFirmware.

Then we can use the free Xorg drivers for sparc also.

I'm also investigating whether the crypto acceleration drivers can be rewritten to support T1, T2 and T3, based on hypervisor documentation, header files and some dtrace analysis.

I just picked up a 2U T2 sparc with 128 threads, 64GB Ram, 10GigE and room for 16 SAS 2" hard drives, cheap, others will do the same.

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.

Regards,

Peter.

----- Original message -----
> This is about as useful a conversation as talking about comparative
> constitutional law as a problem to be solved by exporting good
> constitutions to somewhere suffering from political problems.
> Constitutions and licenses are foundational documents that express a way
> of proceeding in pursuit of shared values and objectives. A great
> license or constitution can't be transplanted or otherwise adopted if it
> doesn't in fact meet a development community where it is and move it
> where it wants to go. It's why there will never be one license to rule
> them all: because there will always be interesting opportunities in
> playing the game by different rules that better suit a productive
> grouping that generally gets along. It's why there will always be forks
> and schisms, even if you can agree on licenses.
> 
> You aren't talking at all about OI's challenges, such as technology debt
> or strategic direction for issues that OI cares about (such as desktop
> technology) analytically. (For example: technology debt in build systems
> is very much a reason why developers are a reasonable first-order
> community consideration at the moment--you can't get to reasonable
> development cadence when you've got a lot of movement in upstreams and a
> great deal of time spent fighting the build system.) I don't see
> reasoning offered for why governance is even the question being posed
> for the OI community, let alone why you need to follow the Debian model,
> as well as it works for Debian.
> 
> Cheers,
> Bayard
> 
> On 13 September 2014 01: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 ...
> > 
> > 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.
> > 
> > That will put your patches on an equal footing as those with commercial
> > interests.
> > 
> > I'd ignore the FUD about legacy platforms, projects that support
> > multiple architectures are more stable for it.
> > 
> > Debian's constitution is minimal and a similar structure will lend
> > strength to all your interests. Why not base your project on one of the
> > most successful free community projects?
> > 
> > Regards,
> > 
> > Peter.
> > 
> > ----- Original message -----
> > > On 12 September 2014 10:24, Nikola M. <minikola at gmail.com> wrote:
> > > > illumos is a project payed by several companies that employed fully
> > > > payed employees to develop it.
> > > 
> > > We have a mixture of commercial interests and unpaid, or at least
> > > unaffiliated, contributors.   The obvious examples to cite are Rich
> > > Lowe in general, or Saso Kiselkov when he was adding LZ4 support to
> > > ZFS.
> > > 
> > > > If people outside those companies want to make changes, it is
> > > > obvious that it is NOT enough just to send some code upstream and
> > > > hope it gets integrated.
> > > 
> > > It is actually the case that, whether or not you work for one of
> > > "those companies", it is _not_ enough to just "send some code".   If
> > > you are an engineer, regardless of your employer or your motivations,
> > > we expect you to provide evidence of several things:
> > > 
> > > - that you have done a full build of the software, and
> > > that you have not induced compiler warnings or
> > > code style issues
> > > - that you have received code review from at least one
> > > person who has worked in similar parts of the code
> > > base already
> > > - that you have tested the software you added or changed,
> > > and any software the behaviour of which you may be
> > > altering
> > > - that you are not breaking public interfaces we expose
> > > to users, so that they can expect at least binary
> > > compatibility
> > > 
> > > If you work for one of "those companies", or not, you are expected to
> > > provide the above.   If you provide the above, and the advocates are
> > > satisfied that you are maintaining the quality of code in the gate,
> > > then your changes will be put back.   It's as simple as that.
> > > 
> > > What is _not_ simple is that from time to time, people propose and
> > > submit changes for review that will break other users of the
> > > software. Or, people propose and submit changes that have received
> > > insufficient review and testing.
> > > 
> > > Just because it's open source, community-developed software does not
> > > mean that we should be lax on quality, or reckless with respect to
> > > backwards compatibility.   For better or for worse, that's why we
> > > accept changes the way we do today.
> > > 
> > > > People need to form clusters of users, Admins, Hosting and
> > > > companies using distributions , to , again, employ their people ,
> > > > pay them or inspire existing employees or Members to contribute to
> > > > make their job easier. More people join such clusters, it is
> > > > better , not to let just a few companies move illumos to ,say
> > > > x86-only , killing SPARC or something else.
> > > 
> > > If (or, frankly, when) we kill SPARC support, it will be because
> > > _years_ have passed without any real engineering effort showing up to
> > > do builds, testing and bug fixing on SPARC platforms.   It is, now
> > > that SPARC is a legacy platform, not reasonable to expect the bulk of
> > > (x86-focused) developers to do work, where platform-specific
> > > differences occur, to prop up code that will likely not be compiled
> > > or run by more than a handful of people ever again.
> > > 
> > > 
> > > Cheers.
> > > 
> > > --
> > > 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/366f34e2/attachment-0005.html>