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

seth Nimbosa darth.serious at gmail.com
Sun Feb 23 08:22:01 UTC 2014


​
Jörg
​, I believe there should be no problem in OS integration of OpenZFS in
illumos.  In fact the concern now is quite the opposite: how to decouple
ZFS from the rest of illumos core technologies and enable clean re-use and
open collaboration.
For no​w ​​the illumOS implementation of ZFS is ok in itself​ ​and fits
well in illumos ​as it is the de facto upstream of all the other
implementations, but a better way to collaborate than today's ad hoc
processes should always be welcome.

 ​
> Date: Wed, 12 Feb 2014 14:28:47 +0100
> From: Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de>
>
>
> The problem with OpenZFS is that is does not have an own code repository.
> In
> addition, I have not yet been able to find the documentation of the general
> method used for implementing enhancements. Once I could review this method
> and
> ​ ​
> it turns out that the current OpenZFS code still fits into OpenSolaris, I
> am
> willing to upgrade.
> ​​
> ​​
>
>
> Jörg
> _______________________________________________
>

​
AFAIK, unification is in progress (?) to integrate the ZFS implementations
​ ​
in different OS'es ​into a platform-independent central repository with
minimal platform code differences. Preliminary efforts will necessarily
include: splitting ZPL into platform-independent and platform-specific
parts; and moving illumos/Solaris-specific code out of the main files, and
probably establishing OpenZFS as an official and separate
​ ​
special ​sub-project (spin-off) under the umbrella of the illumos
Foundation (as the nonprofit organization (NPO) to hold the assets of
OpenZFS) where upstream collaboration can happen between developers of the
different implementations.
​  ​Since OpenSolaris was, and now illumos (as open source successor) is
the source of all these implementations, and as the de facto upstream home
of these, I hope illumos would step up its leadership in this direction.


Here are the links referring to this effort:

Matt Ahrens' suggestion<http://www.listbox.com/member/archive/post_content.html?post_id=20140121130628:B7EACD0C-82C6-11E3-A3C7-8D9CF362376F&address=002>
OpenZFS Developer Summit & Hackathon - Matt
Ahrens<http://blog.delphix.com/matt/2013/12/05/openzfs-developer-summit-hackathon>
OpenZFS Developer Summit - November 18-19,
2013<http://sun.systemnews.com/articles/189/3/zfs/33711>
OpenZFS Developer Summit | deirdre's
notes<http://www.beginningwithi.com/2013/11/18/openzfs-developer-summit>
OpenZFS code repository<http://www.slideshare.net/MatthewAhrens/openzfs-code-repository>
Reduce code differences -
OpenZFS<http://open-zfs.org/wiki/Reduce_code_differences>
OpenZFS platform-independent central
repository<http://open-zfs.org/wiki/FAQ#Are_there_plans_to_merge_the_different_repositories.3F>

​I believe efforts to grow the ZFS community by organizing OpenZFS is a
perfect example and microcosm​ of what has to be done in
illumos/OpenIndiana: growing user-base and implementation by shrinking the
code, namely splitting to manageable pieces to maximize re-use in different
contexts, minimize code differences, hence increase collaboration and
synergy among developers.


Sincerely yours,

Seth Nimbosa,
​
http://twitter.com/nimbosa
FB.com/nimbosa <http://fb.com/nimbosa>


 ---------- ** * ** ----------

* Normal is getting dressed in clothes that you buy for work*
*and driving through traffic in a car that you are still paying for -*

*in order to get to the job you need to pay for the clothes and the car,and
the house you leave vacant all day so you can afford to live in it.  *

  - Ellen Goodman


On Fri, Feb 21, 2014 at 8:48 PM, Joerg Schilling <
Joerg.Schilling at fokus.fraunhofer.de> wrote:

> 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.
>
> Layers can be put on top of something that is able to support the potential
> layers.
>
> If you e.g. create a too small floor slab, you will have no space for a
> terrace
> at your house.
>
> If we like to have success with a common development base, we need to
> create
> such a base in a way that does not prevent some of the participants from
> implementing their goals. This of course only works if the participants
> have a
> veto right for changes that might compromise their goals. Do you believe
> that
> we will be able to have a moderated discussion that leads to such a common
> base?
>
> I suspect that this is the most critical part.
>
> > 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.
>
> Such a minimum will not be created if the common base is missing features.
> We need to find a way to agree on what must be in the minimum set of the
> common
> base and we need to agree on how to add new things.
>
>
> > > 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.
>
> I mentioned that we would need a moderator, if you take this role, let's
> see
> what we can achieve.
>
> Jörg
>
> --
>  EMail:joerg at schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353
> Berlin
>        js at cs.tu-berlin.de                (uni)
>        joerg.schilling at fokus.fraunhofer.de (work) Blog:
> http://schily.blogspot.com/
>  URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20140223/af7b7511/attachment-0005.html>


More information about the oi-dev mailing list