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.

Comments

Post a Comment

Popular posts from this blog

An important milestone

Yesterday, with very little fanfare, illumos passed an important milestone. This milestone was the integration of  195 Need replacement for nfs/lockd+klm This is work that I originally tasked Gordon Ross and Dan Kruchinin to work while we were colleagues at  Nexenta .  Gordon started the work, picking up bits from FreeBSD as a starting point and gluing it to the illumos entry points.  Dan continued with it, and fleshed out a lot of the skeleton that Gordon had started.  It was subsequently picked up by the engineers at Delphix , and -- after some important bug fixing work was completed -- was integrated into their product quite some time ago -- reportedly its been stable since December in their product. The reason this is such an important milestone, is two fold: First, this represents a substantial collaborative effort, involving contributions from parties across several organizational boundaries.  The level of collaboration achieved here is a w...
Read more

GNU grep - A Cautionary Tale About GPLv3

My company, DEY Storage Systems , is in the process of creating a new product around the illumos operating system.  As you might imagine, this product includes a variety of open and proprietary source code.  The product itself is not delivered as a separate executable, but as a complete product.  We don't permit our customers to crack it open, both from the sense of protecting our IP, but also to protect our support and release engineering organizations -- our software releases consist only of a single file and we don't supply tools or source for other parties to modify that file. One of the pieces that we wanted to integrate into the tree is an excellent little piece of software called Zookeeper , produced by the Apache organization.  Like illumos, Zookeeper has a nice non-viral copyleft license, which makes it nice for integration into our product. However, I discovered that as part of our integration, one of my engineers had decided to integrate GNU grep. ...
Read more

The Hand May Be Forced

Well, as you may have read , Oracle has decided that at some point very soon, we're going to lose normal regular access to the source code for OS/Net. (I.e. the Solaris kernel and supporting programs.) While I would have vastly preferred for Illumos to have a cooperative and collaborative relationship with Oracle , it appears that Oracle doesn't value this. In fact, the exact words were from the management at Oracle were as follows: Solaris is not something we outsource to others, it is not the assembly of someone else’s technology, and it is not a sustaining-only product. While I understand the need to own the technology, there are few things that could be stated that show a stronger NIH attitude than this. Its unlikely that there will ever be a way for Oracle and the greater community to have a collaborative relationship. This is a dark day for OpenSolaris -- its effectively dead now. (Its parent, Solaris, lives on however.) How unfortunate. For Oracle that is. Because...
Read more