Thanks for the write-up and diagram, Jeppe.<br><br>I don't think the idea is that "trusted" means that a commit goes right to the repo: I think trusted means if it clears CI, it's good to go. Everyone else has to have eyeballs and peer review. Maybe core people can do manual pushes straight to the repo, but I think that must be a separate level of trust from a developer whose put forward some clean commits. Some areas may not be verifiable through CI (e.g. changes to the userland tools themselves), and I'd suggest those should always require peer review.<br>
<br>One other thing we need is a set of ground rules about what people should change. In particular, I don't think we want to have a lot of volatility in terms of what functionality is or isn't enabled in a component. We need to set a clear expectation that changing those build characteristics must be done with a dedicated issue and changeset, and I'd suggest that such changes are an area where we might want to maintain some kind of peer review just to check consensus. We may not be able to check that programmatically, but the norm should be that doing an end-run around that means losing developer status and having eyeballs on everything you do.<br>
<br>On Sun, Feb 12, 2012 at 9:56 PM, Jeppe Toustrup <span dir="ltr"><<a href="mailto:openindiana@tenzer.dk" target="_blank">openindiana@tenzer.dk</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">


To quickly talk through it - new developers first of need to have a<br>
user on GitHub. That way they can create a fork of the<br>
illumos-userland repository on the site. They should create a new<br>
branch on their own fork for each change/package they want to add,<br>
since they then can put in a pull request to get the changes from one<br>
branch merged into the illumos-userland main repository.<br>
<br>
When a pull request gets in, it will trigger a build in Jenkins.<br>
Jenkins will then write a comment on the pull request with the results<br>
of the build. In case it failed, the contributor can work further on<br>
the code, and when new commits are added to the branch, it will start<br>
a new Jenkins build.<br>
<br>
When the build gets successful, the pull request will be tagged with<br>
"needs review", which then requires a moderator/trusted developer to<br>
look through the patch and accept it, or let the contributor know of<br>
any changes which may be required before we can accept it.<br>
<br>
<br>
For trusted developers, they can choose one of two things (this should<br>
probably be up for discussion).<br>
1. Commit directly into the illumos-userland repository, the most<br>
direct way of putting stuff in.<br>
2. Create the commits as they normally would, but instead of pushing<br>
them directly to illumos-userland, they make a pull request in order<br>
to get the commit checked by Jenkins. If the build is successful, we<br>
can make Jenkins accept the pull request by checking the user who made<br>
the pull request against the list of users with commit access to<br>
illumos-userland.<br>
<br>
Ideally everything should go through a pull request in order to get<br>
built by Jenkins so we make sure the code in illumos-userland can be<br>
build at all times. It only requires one extra step - to go and create<br>
a pull request, which basically just is a matter of clicking a button,<br>
and shortly describe what the pull request does. It is however up to<br>
the developers if they think this is reasonable or not.<br>
<br>
--<br>
Venlig hilsen / Kind regards<br>
<span><font color="#888888">Jeppe Toustrup (aka. Tenzer)<br>
</font></span><div><div><br>
_______________________________________________<br>
oi-dev mailing list<br>
<a href="mailto:oi-dev@openindiana.org" target="_blank">oi-dev@openindiana.org</a><br>
<a href="http://openindiana.org/mailman/listinfo/oi-dev" target="_blank">http://openindiana.org/mailman/listinfo/oi-dev</a><br>
</div></div></blockquote></div><br>