[oi-dev] Resignation

[Bayard Bell]

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/426829e1/attachment-0005.html>