<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

<html><head>

    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

    <meta name="generator" content="Osso Notes">

    <title></title></head>

<body>

That's rich, a project with no stable release baseline to measure binary compatibility against won't accept patches unless ...

<br>

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.

<br>

That will put your patches on an equal footing as those with commercial interests.

<br>

I'd ignore the FUD about legacy platforms, projects that support multiple architectures are more stable for it.

<br>

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?

<br>

<br>Regards,

<br>

<br>Peter. 

<br>

<br>----- Original message -----

<br>> On 12 September 2014 10:24, Nikola M. <<a href="mailto:minikola@gmail.com">minikola@gmail.com</a>> wrote:

<br>> > illumos is a project payed by several companies that employed fully

> > payed employees to develop it.

<br>> 

<br>> We have a mixture of commercial interests and unpaid, or at least

<br>> unaffiliated, contributors.   The obvious examples to cite are Rich

<br>> Lowe in general, or Saso Kiselkov when he was adding LZ4 support to

<br>> ZFS.

<br>> 

<br>> > If people outside those companies want to make changes, it is obvious

<br>> > that it is NOT enough just to send some code upstream and hope it gets

<br>> > integrated.

<br>> 

<br>> It is actually the case that, whether or not you work for one of

<br>> "those companies", it is _not_ enough to just "send some code".   If

<br>> you are an engineer, regardless of your employer or your motivations,

<br>> we expect you to provide evidence of several things:

<br>> 

<br>>     - that you have done a full build of the software, and

<br>>               that you have not induced compiler warnings or

<br>>               code style issues

<br>>     - that you have received code review from at least one

<br>>               person who has worked in similar parts of the code

<br>>               base already

<br>>     - that you have tested the software you added or changed,

<br>>               and any software the behaviour of which you may be

<br>>               altering

<br>>     - that you are not breaking public interfaces we expose

<br>>               to users, so that they can expect at least binary

<br>>               compatibility

<br>> 

<br>> If you work for one of "those companies", or not, you are expected to

<br>> provide the above.   If you provide the above, and the advocates are

<br>> 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.

<br>> 

<br>> 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.

<br>> Or, people propose and submit changes that have received insufficient

> review and testing.

<br>> 

<br>> Just because it's open source, community-developed software does not

<br>> mean that we should be lax on quality, or reckless with respect to

<br>> backwards compatibility.   For better or for worse, that's why we

> accept changes the way we do today.

<br>> 

<br>> > People need to form clusters of users, Admins, Hosting and companies

<br>> > using distributions , to , again, employ their people , pay them or

<br>> > inspire existing employees or Members to contribute to make their job

<br>> > easier. More people join such clusters, it is better , not to let just

<br>> > a few companies move illumos to ,say x86-only , killing SPARC or

<br>> > something else.

<br>> 

<br>> If (or, frankly, when) we kill SPARC support, it will be because

<br>> _years_ have passed without any real engineering effort showing up to

<br>> do builds, testing and bug fixing on SPARC platforms.   It is, now that

<br>> SPARC is a legacy platform, not reasonable to expect the bulk of

<br>> (x86-focused) developers to do work, where platform-specific

<br>> differences occur, to prop up code that will likely not be compiled or

> run by more than a handful of people ever again.

<br>> 

<br>> 

<br>> Cheers.

<br>> 

<br>> -- 

<br>> Joshua M. Clulow

<br>> UNIX Admin/Developer

<br>> <a href="http://blog.sysmgr.org">http://blog.sysmgr.org</a>

<br>> 

<br>> _______________________________________________

<br>> oi-dev mailing list

<br>> <a href="mailto:oi-dev@openindiana.org">oi-dev@openindiana.org</a>

<br>> <a href="http://openindiana.org/mailman/listinfo/oi-dev">http://openindiana.org/mailman/listinfo/oi-dev</a>

<br><br></p>

</body>

</html>