<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On each occasion the conclusion reached was that Gerrit would be<br></div>
difficult to maintain and would increase the complexity involved for<br>
pre-existing contributors.<br></blockquote><div><br></div><div>On big/complex projects contributors are using branches instead of the reviewboard,</div><div>because it is to difficult to keep track on which changes has be done. Also with git diff</div>
<div>it is more difficult to avoid git conflicts. Furthermore testing big patches with git diff is not</div><div>possible. For examples on kdelibs-frameworks. So contributors MUST learn how to handle </div><div>git branches and merges between their branch and the origin one. Which sometimes, is very</div>
<div>stressful for the contributor, also some mistakes are happen. And as a result of that, the mentors </div><div>and the contributors are losing a lot of time in order to fix those.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Among the issues found:<br>
- Gerrit implements the git protocol itself, and has an internal SSH server.<br>
- Changes would be necessary to integrate it with Identity as we store<br>
SSH keys in Identity. It is not clear how invasive these changes would<br>
be.<br></blockquote><div><br></div><div>In my opinion, before we make a big change into our infrastructure, we must</div><div>first test it. Because without testing, we cannot be sure if the new infrastructure</div><div>
is useful/harmful for our community. Also big changes like that should not be</div><div>applied in the whole KDE. Because they might create some panic. So in my</div><div>opinion the best think that we have to do is to search for some teams which </div>
<div>they want to test it, and based on the result, then we can either start applied the </div><div>new infrastructure to the whole KDE or we could just reject the idea.</div><div><br></div><div>Of course a new infra might not cover our needs with its original structure, so we could</div>
<div>keep both gerrit and reviewboard. And as regards the contributors, they can choose which</div><div>one they want to use.</div><div><br></div><div>Also when KDE moved from svn to git, the amarok was one of the projects which was moved </div>
<div>to the gitorious. In order to test if the gitorious fit our needs. So since we are talking about the infra</div><div>i do not see a valid reason for which we should not do the same here.</div><div><br></div><div>As regards the ssh keys, gerrit allows the contributor to upload his ssh key and a "trusted" user to </div>
<div>approve it. So this close the security issue. Also in order for someone to take git access, he need someone</div><div>to approve him. So it is clear that when a developer from plasma,kwin,kdelibs,amarok etc is approving someone</div>
<div>then it is his own responsibility to choose wise, before he says the "ok".</div><div><br></div><div>As regards the contributor, it is clear enough that people that don't know how to copy/paste their ssh key into</div>
<div>gerrit, that they don't even know what git means. So those people are not ready to have access on those tools.</div><div>They could simple use the reviewboard.</div><div><br></div><div>Of course the above idea is just a "work around", i don't say that this will be our policy but until we decide if</div>
<div>gerrit is good for us or not, then it will simple do its work :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Gerrit is a Java application, and past experience with them indicate<br>
that are very resource intensive.<br>
- Gerrit operates with the assumption it has permission to push to the<br>
master repositories, providing a security vulnerability to our<br>
infrastructure.<br>
- Permissions would need to be duplicated between Gerrit and Gitolite,<br>
the system responsible for managing git repositories on <a href="http://git.kde.org" target="_blank">git.kde.org</a>.<br>
<br>
The security of <a href="http://git.kde.org" target="_blank">git.kde.org</a> and <a href="http://svn.kde.org" target="_blank">svn.kde.org</a> is something which can<br>
never be affected or weakened in any form.<br>
<div class="im"><br></div></blockquote><div><br></div><div>After we test gerrit, we could simple decide if we have the infra which is</div><div>required or not.</div><div>Also on active projects, the mentors are using the <a href="http://commitfilter.kde.org">commitfilter.kde.org</a></div>
<div>and the rss from the <a href="http://projects.kde.org">projects.kde.org</a>, so they could see if there is a bug</div><div>or some kind of an abuse. After all this is the meaning of the "testing".</div><div>
<br></div><div>EVERY change into the infra might cause some security issues but there</div><div>is nothing that we can do with that. Also your custom patches might not work</div><div>without a little adjustment BUT when you rewrite an application or the infra this</div>
<div>is something that cannot be avoid. Also if we always want to have an</div><div>application/infra which was going to be 98% secure (there is nothing like 100% SAFE :))</div><div>then we shouldn't move from git to svn and we shouldn't move from KDE3 to KDE4.</div>
<div>In every thing there are cons and ads. The point is if there are more ads than the cons. :)</div><div><br></div><div>Also KDE4 is much bigger than the KDE3 was. And KDE5 will be even bigger.</div><div>So we must change our infra in order the mentors will not lose time trying to </div>
<div>fix the mistakes of the contributors which might happen because of a bad merge</div><div>or push. Also gerrit can build projects or try to see if their unit tests are 100% ok.</div><div>So WITH GERRIT will we be able to reduce the REGRASSIONS!!!</div>
<div><br></div><div>In conclusion, i think that we should use gerrit because it will simple make our lives</div><div>easier and our code better :)</div></div><br>