Changes to illumos Contribution Process

First off, let me state that the following changes are aimed at both easing the challenging of contributing changes to illumos, while increasing our level of "confidence" in what changes are being integrated into our source code tree.

Up until now, illumos has used a contribution model that is primarily derived from the model used within Sun and Oracle for Solaris development.

This development model is based on the notion that all contributors have (or had at least) the direct ability to "push" code to the repository, after a certain number of review steps had been followed.

This model works well with a small team, or where all contributors are reasonably well trusted. This is also not typical at all of the way most FOSS projects work. (Indeed, with OpenSolaris, this model was not used for external contribution.)

Going forward, we want to enable a much wider group of developers, some of whom may not hang around long enough in our community to get a high level of "trust".

We also want to enable a contribution process that is more similar to what other FOSS projects use.

So, to this end, we are going to move from "developer push" to "advocate pull". "Advocates" are just our version of "maintainers" or "gatekeepers". (The Linux equivalent of this is Linus' "lieutenants".)

So now, rather than developers pushing changes directly to our mercurial tree, going forward Advocates will take patches from Contributors (either via hg export or patch file), verify that the content of the patch is what was reviewed, and will then be responsible for integrating those changes into our shared master.

Note that as part of this process, the Advocate will be ensuring that the original Contributor is still credited in the SCM change history. So Contributors still get credit for their work.

Also, we will still be insisting on other parts of the contribution process that we already have, such as code review, testing, and verification of legal right to receive the contribution.

The main implication for Contributors is that they can supply changes in the form of regular patches, which frees them from having to deal directly with one SCM or the other (more on that below). The other

implication is that if a merge conflict occurs that the Advocate can reject a change and ask the contributor to resolve the conflict and resubmit.

Note that this whole process is much much more similar to the process used by other big name open source projects, such as Linux.

At this point, I'd like to point out that we have a "clone" of illumos-gate on github. So you can use git if you want to. We also have an hg clone at bitbucket.

For now, Advocates use hg as our "master" repository, but we are also talking about a conversion to git to make life better. That's a more detailed topic of conversation, but mostly the concern about whether we are using git or hg should be irrelevant to contributors, as they can use either and are not directly exposed to the integration step (hg push or git push for example.)

The final tidbit here is that we need to set up a public page with a list of Advocates, but for now the list of illumos-gate Advocates is:

• Garrett D'Amore
• Albert Lee
• Rich Lowe
• Gordon Ross

As more people contribute and demonstrate a level of throughness and trustworthiness, I hope the above list will expand somewhat.

illumos sysad/integrator position (NYC)

I have an illumos partner that is interested in finding a strong system administrator/system integrator candidate for work on an illumos-based product in New York. Candidates need to be strong with Solaris, security, scripting (perl, python and/or ruby, etc.) and should have cross platform experience. If this sounds interesting to you, please contact me directly.

need C programmers/interns in So. Cal.

I'm looking to hire a few really smart folks who can work in southwest Riverside County, CA (near Temecula, CA). I want people who are sharp C programmers, want to work on open source kernel software, and are eager to stretch themselves. This is a great learning opportunity. If you know anyone like that, let me know!

illumos update in LA

I'll be giving an update on illumos, as part of my talk in LA this evening. If you're around, please join us!

beadm provided in "C"

I know this is somewhat controversial for some people, but....

A member of my staff (Alex Stetsenko) has pushed an implementation of "beadm" that is in C. This is actually derived from an earlier C implementation we already had in tree, called "tbeadm", which we already had. So at some level, this consolidation of two different implementations into a single one. As part of this work, the tbeadm version was modernized and improved to provide i18n capabilities and to behave truly as a drop-in replacement for the python version.

As a result of this change, python is no longer needed at runtime by illumos for anything except IPS packaging. Sites and distributions which do not use IPS packaging (most distros don't, actually) no longer need to install python.

Any illumos fans near Corinth, MS?

I drove across country last weekend, and am in Corinth, MS. I'd be happy to go out for a beer and some chat if there are any illumos fans or OSUGs nearby this week.

I sed(1) so!

I just integrated a new sed(1) port for illumos. This is derived from FreeBSD, but it includes a fix for a race condition, and support for translated messages. (FreeBSD friends, please feel free to include these changes back -- I've not changed the original BSD license.)

The legacy sed is gone.

This new sed should work on all the old sed scripts, but there were a few tricky parts that changed -- if you relied on parsing the output of the "l" command, or on the fact that legacy sed only treated content as a byte stream rather than multibyte characters, you might be affected.

Also, I've run into at least one sed script which was malformed, but mistakenly accepted by old sed, but which the new version doesn't accept (but instead gives you a meaningful error message.)

The biggest features in the new sed code:

1. support for -i and -I
2. support for -E to enable EREs
3. much more helpful error messages ("command garbled" was just not very specific)

Enjoy, and please report any problems in the illumos bug tracking system at http://illumos.org/. Thanks!

Update: Note that sed -i requires an argument (the extension) unlike GNU sed where the argument is optional. We can fix that, although this would make us less compatible with FreeBSD sed. (Specifically, it would make it nigh impossible to specify an "extension" starting with a dash.) If someone cares passionately about this, they should file a bug and bring it up on the developer list -- I am happy either way.