[oi-dev] Resignation

[Peter]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20140913/5300af7e/attachment-0005.html>