[illumos-Discuss] Bounty for porting OpenSolaris to ARM

[Garrett D'Amore]

On Tue, 2010-10-19 at 20:26 +0200, Chris Pickett wrote:
> On Mon, Oct 11, 2010 at 3:10 PM, Garrett D'Amore <garrett at damore.org> wrote:
> > On Mon, 2010-10-11 at 14:58 +0200, Chris Pickett wrote:
> >> On Mon, Oct 11, 2010 at 1:05 AM, Icy EyeG <icy.dearchild at gmail.com> wrote:
> >> > Hi all,
> >> > I don't know if the developers of Illumos already know this, but there's a
> >> > non profit organization called Power2People that is hosting a bounty for
> >> > porting OpenSolaris to ARM, funded by Genesi.
> >> > Details of the bounty here: http://www.power2people.org/bounty_044.html
> >> >
> >> > Power2People has hosted multiple bounties already for AROS, and thanks to
> >> > it, AROS has improved tremendously. I hope it can do the same to
> >> > OpenSolaris/Illumos.
> >>
> >> I like to get a clear word from Nexenta *first* before anyone spends
> >> time with such a project:
> >
> > First off, Nexenta doesn't have the final word here.  If the
> > developer-council and advocates agree that this (or any other project)
> 
> Who is the developer-council and how can a company contact them? Who
> are the advocates?

Developer council members:

Garrett D'Amore
Bryan Cantrill
Jim Carlson
Adam Leventhal
Richard Lowe

Contact by e-mail to developer-council@


The advocates at present are Rich Lowe, Gordon Ross, and Garrett
D'Amore.  I'm hoping to grow this particular list as soon as we see
other folks with a sufficient number of quality contributions (where
quality is both content and well-formedness), and with enough attention
to detail to be trusted to enforce the same quality rules universally.

> 
> > either should or should not be integrated, then that decision will be
> > binding.  (The fact that significant leadership of the project are
> > Nexenta employees is a red herring.)
> 
> How can the community get clarity before a project is created? IMO no
> one here is willing to be the next Hans Reiser and get his work of
> many years rejected because it does not follow the spirit of the
> kernel coding style or similar nonsense cover for political issues.

Start with a discussion on developer at lists.illumos.org is the best
choice.

Generally coding style, quality rules, testing rules and such are mostly
the same as for ON.  If you want to do something questionable there, you
should contact one of the leadership.

You *always* have the option of forking or creating a new workspace.  If
your work is sufficiently meritous, then other people will almost
certainly want to see it integrated, and you'll have a much stronger
case.

> 
> >> Will such an ARM port be developed and maintained as part of the
> >> Illumos main hg repository or will it be delegated to a different
> >> repository and never be integrated into the mainline?
> >
> > If the porters can convince us that:
> 
> Who is us?

Generally, the advocates, and if contentious, the developer-council.

> 
> >
> >
> >        a) They are ready from a quality standpoint, and
> 
> This must be precisely defined and binding for ALL contributors, even you.

Every component has different rules.  I'd say generally, is free from
major known defects, and has been reasonably tested.  If you want a more
precise definition, sorry, you won't get one.  Attempting to create such
a precise definition will hamstring other useful development, and burn a
lot of cycles trying to fit square pegs into round holes.

For a major new port, I'd say quality would mean general stability and
free from crashes.  The code should pass lint, and be able to self host,
ideally on a reasonable mix of appropriate hardware or configuration
options.  (I'm not certain what those hardware options would look like;
I think we'd pursue finalizing that as part of a preliminary review of
the project.)

For a project so large as this, I'd also like to see a test plan.  I
always provide test results to advocates on integration; any advocate
that integrated a major change like this without adequate evidence of
testing would probably have his advocacy yanked.

The quality checks are enforced by the advocates, and *all* integrators
must have both code review and integration review.  That includes me,
and it includes anyone else.

> 
> >        b) They have long term commitment to supporting the code, and
> 
> That's reasonable.
> 
> >        c) That we can get some some sample hardware to build and test on, and
> 
> That's reasonable.
> 
> >        d) There are no other reasons (licensing, or otherwise) why they should
> > not be integrated,
> 
> What are the other reasons. Please elaborate. The community and
> potential companies joining Illumos need clear definitions. before
> spending their money. See Reiser4. See OpenOffice.

I can't enumerate them all, because I can't foresee them all.  License
incompatibility would be a major one.  Major architectural impact on
other areas of the system, or major unresolved technical disputes
*might* be one.  A change that introduced a great deal of risk for
little or no reward might be another one.  (A good example of the latter
might be reinstating 32-bit SPARC CPU support... virtually no reward,
and lots of risk to the rest of the SPARC tree.)

If you're wanting a promise that says "do A and you will automatically
get to integrate", sorry, its not that clean cut.

We will always try to do what makes *sense*.  If there is dispute, then
developer-council is the next avenue for resolution.  If a situation is
unresolvable there, then tech-lead (atm that's me) has the final word.

My strongest advice for someone looking to undertake a major effort
would be to approach the leadership early, and often.  Dropping 100KLOC
in our lap and asking to us integrate it without previous communication
is likely to lead to failure.

> 
> > then I see no reason why ARM support could not be integrated into
> > illumos.
> 
> That sounds good..
> 
> Chris

Hopefully this clears it up somewhat.

	- Garrett