[oi-dev] [discuss] Re: basis for better collaboration on illumos and OpenIndiana: small circle, Big circle

Thu Feb 20 20:32:57 UTC 2014

See this: http://www.slideshare.net/vishnu/how-to-protect-yourhow-to-protect-your-open-source-project-from-poisonous-people

illumos itself is a *meritocracy*, which means leadership is shared by those who are doing the most for its benefit.  Folks who want to have more say in where we’re going should start by proving their merit (ideally with code) rather than just whinging.

For those of you who are unhappy with the decisions we have made for illumos (and there have been very very few “decisions”), please consider whether you are participating in our meritocracy.  In a collaborative environment, everyone is working for the common good.  Collaboration is *not* throwing stones at the work of others, or working against the common good.  Sadly, at least some of the individuals that have been participating in this thread have acted in ways that fit this pattern — i.e. they would be considered “poisonous people” per the slideware above. 

I’m trying *very* hard not to name names, and not to include extensive evidence of actively harmful activities that some of these folks are *still* engaging in — working very hard against some of the most valuable (in terms of positive contribution) people in our community.  You can only begin to imagine how *angry* threads like this one makes me, if you had knowledge of these subversive and destructive activities.

So, please, go take this conversation somewhere else.  It isn’t about illumos.  It might be about OpenSolaris — but I think Oracle will have some things to say about that (OpenSolaris is dead, did you hear?), but it absolutely *isn’t* about illumos, and it doesn’t belong here.

-- 
Garrett D'Amore
Sent with Airmail

On February 19, 2014 at 7:34:58 PM, seth Nimbosa (darth.serious at gmail.com) wrote:

The reason we need a minimum of criteria for collaboration is precisely because the different distributions have different focus, approach, and use case scenarios in mind, but a set of core features that will make it to a unified kernel will be for everyone's benefit.  Additional layers will be built upon this basic core and the abstraction of these feature-sets and their encapsulation from the layers below and above it will ensure that there is more or less a predictable and uniform way each of these layers interact together and how they behave on top of the core.  I mean each distro-specific feature-set will be spun out and encapsulated into separate layers of development on top of the kernel (and these layers will be slightly or wildly different in each distribution) but the core will remain mainly intact but dynamically developed jointly by the different distros in an upstream manner.

For example, support for Linux platform ABI through branded zones like "Solaris Containers for Linux Applications" (SCLA) has been implemented by Sun before.  This is possible because there is a Linux platform ABI to speak of.  It makes sense if we can agree on a minimum set of behavior and features that make up an OpenSolaris-based platform ABI, implemented through a smaller standard reference distribution that will embody this minimum standard, like a smaller text-based OpenIndiana server install or LiveCD that will serve as reference, example and basis of other distros that will build layers of additional layers on top of it.  We must reckon that Solaris itself in the beginning was the direct result of unification efforts by AT&T, Sun and others, and so SVR4 was born which was the basis and foundation of many later UNIX systems and other OS'es and so on.  I think it's not too late to gather the efforts of our separating communities in the different branches of OpenSolaris-based distros to arrive at s single standard like the mainline Linux kernel, and a jointly-developed single reference distro like Sun's OpenSolaris LiveCD in the past, resulting in a slim OpenIndiana which can be a reference to other distros or even as a basis for a larger full-featured GUI-based OpenIndiana LiveCD.

on Mon, Feb 17, 2014 at 5:38 AM, David H <davidhalko at gmail.com> wrote:
>
>    Collaboration Criteria:
>    - The original promise was for both Intel & SPARC in the community,
>    that promise should be kept.

I believe so, too. I have been in contact with Martin Bochnig and he is very positive about collaboration and unification efforts.  He is willing to release his progress so far and will be putting up a wiki to explain his process and recipe for x86, x86_64 and SPARC architectures.  He has been collaborating with DilOS folks and I know things will be better the moment we start plotting their development against how ilumos-kernel has evolved and how OpenIndiana has grown.  The key factor here is: how much code from OpenSolaris has been discarded simply because Nexenta or Joyent has found no use for it?  I believe there may be many such valuable artifacts (like SPARC support) from Sun's OpenSolaris that has been lost, because slashing them was expedient and caused "less" bugs.  Another factor is: what improvements have been developed outside of the ambit of illumos-OpenIndiana circles, by other branches like SchilliX, Belenix, MartUX/OpenSXCE, DilOS, XstreamOS, OmniOS, etc.?  David, you have a very good partial list, and to be frank yes! many oppotunities indeed passed by, but I think the best is yet to come.  Thanks Srinam for dropping that Belenix is also underway.

>    Collaboration should be to pool resources to expand the ecosystem -
>    not pool all available resources in order to keep the ecosystem
>    limited in overall scope.
>
>    Thanks, Dave

AMEN to that.

The tug and pull of Jorg and Peter's arguments is healthy for our community.  This way we can strike a balance between the tyranical standard approach with a rigid set of feature compliance and the very fuzzy definition of what OpenSolaris-based distros are evolving into.  By keeping our criteria for collaboration at a minimum, we are inviting more synergy between developers on the basic general stuff and at the same time promoting more choices how to implement different solutions to the same familiar problems and opening more ways to implement new solutions to needs unforeseen or poorly addresed before.

To quote Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de>
at another instance (Wed, 12 Feb 2014 14:28:47 +0100):
>
> "Collaboration is a result of promises and credibility by implementing said promises. Collaboration is also a result of compromises. If you are not willing to make compromises, you try to dictace what other people may do and this is not compatibile with collaboration.
>
> I am open for a collaboration for OpenSolaris as long as there is room for different goals in the different distros."

Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de>
(Thu, Feb 13, 2014 at 5:35 PM):
>
> If you like to collaborate between different projects, this will need both sides to make compromises and to give enough room so the other side is able to have a benefit.
>
 > I am willing to give other people enough room and I guess that you would do the same. So let us see whether OI is willing to colaborate. As I mentioned since a long time: OpenSolaris has not enough people to make each job twice, so we need to collaborate if we like OpenSolaris to survive.
>
>
> Jörg

We must put this to practice.
I believe the best is yet to come for free OpenSolaris-based systems.

Sincerely yours,

Seth Nimbosa,
 http://twitter.com/nimbosa
FB.com/nimbosa

___________________________________________
> On Thu, Feb 13, 2014 at 5:35 AM, Joerg Schilling
> <Joerg.Schilling at fokus.fraunhofer.de> wrote:
> > seth Nimbosa <darth.serious at gmail.com> wrote:
> >
> >> I think the general idea is to get to a minimum criteria as basis for wider
> >> collaboration.  We have to start small and manageable and agreeable. Then
> >> others will follow if they see the benefits of that working together for a
> >> healthier code and healthier community guidelines, then there will be lower
> >> barriers for participation, more consensus-building and pooling together
> >> the best solutions out there.
> >
> > It is more than a minimum criteria, we need (as mentioned yesterday) an opening
> > towards OpenSolaris goals that do not prevent collaboration because of
> > artificial limitations in a single development branch.
> >
> > For me, it is important that OpenSolaris keeps the ability to be ported to
> > embedded systems. This reqires some decisions made by Sun and others made by
> > Illumos to be reverted. So the following requirements are important:
> >
> > -       Keep support for 32 bit kernels (at least for one CPU target)
> >
> > -       Keep support for a UFS root filesystem
> >
> > -       Keep support for /usr being on a different FS than /
> >
> > -       Allow it to be on a tiny system where you cannot afford the monster
> >         ksh93 to allocate several MBs on a tiny root FS. This requires support
> >         for the Bourne Shell for all scripts that need to be run before /usr
> >         is mounted, which means to fix 6 shell scripts modified by Sun in
> >         spring 2010.
> >
> > Other criteria are support for SVr4 package meta data. This may need to add
> > support for specific SVr4 meta data that did not exist in 2010 already. Note
> > that I did enhance the SVr4 packaging for SchilliX-ON already and there will
> > be further enhancements in the future. There is e.g. a plan to add some high
> > level functions seen on IPS to be added to "pkgadm". There is also a plan to
> > allow longer names and to add category based entries in the metadata. The
> > latter is partially already in SchilliX-ON.
> >
> > We need an ABI definition for OpenSolaris.
> >
> > We should have an architecture commitee that should at least give a base for
> > simple additions that do not cause incompatibilities. To make some examples
> > from the SchilliX-ON development:
> >
> > -       grant the libraries to run e.g. star and the new enhanced Bourne Shell
> >         to be present. This is e.g. /lib/libschily* /lib/libshedit*
> >         /lib/libxtermcap*. These libraries are in SCHILYsystem-library-schily*
> >         SCHILYsystem-library-schily-root and SCHILYsystem-library-schily are now
> >         part of the basic system dependencies, so you cannot install a system
> >         without it.
> >
> > -       Add POSIX enhancements like the %r printf format that I am currently
> >         proposing for the next POSIX version. The first implementation already
> >         exists and will appear soon on SchilliX-ON (after the discussion on
> >         the standard commitee did settle).
> >
> > -       Add syscall enhancements like a planned method to allow a process to
> >         aquire enhanced privileges without the need for a exec*() call.
> >         Since 24 months, cdrtools may be installed non-suid-root without
> >         the need for the current wrapper scripts. This is currently implemented
> >         by a re-exec in cdrecord/cdda2wav/readcd, but this could be done by a
> >         new function to the privsys() call to avoid a re-exec.
> >
> > I am sure that other ON development branches have own code too, that might be
> > of general interest if it is not in conflict with a previous ABI.
> >
> >> I am inviting Alasdair, Peter Tribble, Jörg Schilling and Martin Bochnig to
> >> discuss this and find the best way forward in creating this smaller circle
> >> to create greater trust and more support from within the
> >
> > I tried this already several times in the past, but maybe it is better to have
> > a moderator that is not involved in an own development branch.
> >
> > To be able to start, we need to talk about what we are doing and be open for
> > the contraints that need to be met in order to permit a collaboration.
> >
> > e~A
> > -------------------------------------------

illumos-discuss | Archives  | Modify Your Subscription	
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20140220/665e3c1e/attachment-0005.html>