<div dir="ltr">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.<br><br>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.<div><br>Cheers,<div>Bayard<br><div class="gmail_extra"><br><div class="gmail_quote">On 13 September 2014 01:28, Peter <span dir="ltr"><<a href="mailto:jini@zeus.net.au" target="_blank">jini@zeus.net.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>

<div>

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><span class="">

<br>Regards,

<br>

<br>Peter. 

<br>

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

<br></span></p><div><div class="h5">> On 12 September 2014 10:24, Nikola M. <<a href="mailto:minikola@gmail.com" target="_blank">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" target="_blank">http://blog.sysmgr.org</a>

<br>> 

<br>> _______________________________________________

<br>> oi-dev mailing list

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

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

<br><br></div></div><p></p>

</div>

<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" target="_blank">http://openindiana.org/mailman/listinfo/oi-dev</a><br></blockquote></div><br></div></div></div></div>