On Tue, 2010-10-19 at 20:26 +0200, Chris Pickett wrote: > On Mon, Oct 11, 2010 at 3:10 PM, Garrett D'Amore <[email protected]> wrote: > > On Mon, 2010-10-11 at 14:58 +0200, Chris Pickett wrote: > >> On Mon, Oct 11, 2010 at 1:05 AM, Icy EyeG <[email protected]> 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 [email protected] 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 _______________________________________________ Discuss mailing list [email protected] http://lists.illumos.org/m/listinfo/discuss
