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