[illumos-Developer] Changes to illumos Contribution Process

[Garrett D'Amore]

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.

	https://github.com/illumos/illumos-gate

So you can use git if you want to.  We also have an hg clone at
bitbucket:

	https://bitbucket.org/illumos/illumos-gate/overview

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 at nexenta.com    Garrett D'Amore
     trisk at nexenta.com	    Albert Lee
     richlowe at richlowe.net  Rich Lowe
     gwr at nexenta.com	    Gordon Ross

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