Workflow Idea for 4.10

[Antonis Tsiapaliokas]

>
> 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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20120312/f0130e4b/attachment-0001.html>