[Kde-scm-interest] Integrating Reviewboard with git branches

[Ben Cooksley]

On Tue, Feb 5, 2013 at 12:15 PM, Oswald Buddenhagen <ossi at kde.org> wrote:
> On Mon, Feb 04, 2013 at 11:51:31PM +1300, Ben Cooksley wrote:
>> On Fri, Feb 1, 2013 at 6:18 AM, Thomas Koch <thomas at koch.ro> wrote:
>> > I'm not involved in KDE but I'd love to see another big project realizing the
>> > beauty of gerrit. I've some comments inline:
>>
>> Does this include the user interface? The parts I have seen of it are
>> not user friendly at all...
>>
> one needs to get used to it and the ugliness and some quirks, but
> generally it's very usable. how else do you think would 200+ people in
> the qt project use it for their daily work?
>
>> I suspect that Gerrit would complicate our existing process and
>> introduce barriers to entry.
>>
> no, it wouldn't. you should rtfm finally. qt-project has an excellent
> intro wiki.
>
>> This is particularly concerning because some existing developers
>> already have problems with Git itself, and I fear Gerrit would simply
>> complicate this process even further.
>>
> while there are a few (well, two) more steps to take into account,
> gerrit's review-only mode inherently catches most screwups before they
> hit the repository, and consequently contributes to a less scary
> learning experience.
>
>> The integrity of the master Git repositories can never be called into
>> question.
>>
> there is no higher risk of screwin up the repos than with any other git
> server.

See what happened to Github and Rails. The web frontend was
compromised and an unauthorised person was able to push code directly
into the Rails repository.

>
>> A public facing web server is less secure and could be subject to
>> compromise far easier than our existing system.
>>
> i don't see how gerrit's built-in webserver should be inherently less
> secure than all the other systems we have running.

Currently, any changes to access controls or the addition of SSH keys
requires that they be manually synced by a Sysadmin.
As such, our system is only accessible via SSH, which is a much
smaller level of exposure. The master Git repositories are not web
accessible.

>
>> > Have you seen the eclipse integration of gerrit? You don't want to use the web
>> > interface anymore once you saw it.
>> > http://koch.ro/temp/gerrit_skillsmatter.mp4 (minute 12)
>>
>> I doubt a majority of KDE Developers use Eclipse. Applications such as
>> KDevelop and Qt Creator would be more more likely candidates.
>>
> there is a somewhat rudimentary qtcreator integration. patches welcome.
>
>> - From what I see Gerrit requires that an administrator register all
>> new repositories, which is incompatible with our approach of allowing
>> developers to create scratch repositories freely, as well as clones of
>> mainline repositories.
>>
> there is absolutely no reason why there cannot be a web frontend for the
> administrative functions.

You missed my point. Keyword is 'Administrator' - ie. you would have
to ask a Sysadmin to setup even a scratch repository for you.

While I don't have a problem with delegating certain levels of access,
I do have a problem with granting access to all developers to
administer all repositories, as this would allow manipulation of the
sysadmin/* and websites/* repositories, which are protected for very
good reasons. I doubt Gerrit supports delegating access to create
repositories which is limited by a regular expression (which is
basically how Gitolite works at the moment).

>
>> - We would also have to configure each newly created repository
>> explicitly to permit direct pushes assuming it supports that
>>
> that can be done in the default settings.
>
>> (not permitting direct pushes is unacceptable).
>>
> yeah? why? because people would suddenly have to consider the part of
> the policy which says that commits should be atomic (and thus the
> history needs to be cleaned up properly for review?).
>
> in fact, i'd strongly recommend *against* allowing direct pushes (to the
> baseline branches).
> for one, forced review (even self-approval) inherently raises the
> quality. (and *no*, it's *not* an unbearable complication of the
> workflow or even a barrier to entry.)
> second, from experience i can tell you that people will often
> accidentally direct-push when they mean to push for review. that's a
> downside of the good integration with git ...
> third, the possibility to uniformly implement automated checks as review
> bots is a very powerful feature.

If you want to implement such policy, it will have to be referred for
extensive review on kde-core-devel, as well as other project specific
mailing lists.
It constitutes a core change to our workflow which no individual or
particular group within KDE has the right to impose upon others.

Until otherwise known, the policy of direct pushes being inviolable
remains a requirement of all repositories on git.kde.org.

>
>> - KDE will need to continue to keep Subversion alive for translators
>> indefinitely at this point. Our current migration path involves using
>> functionality built into Gitolite which permits one to pass-through
>> Subversion requests. A migration to Gerrit would kill this path -
>> requiring the maintenance of a separate system (with SSH keys,
>> accounts, etc to match - which Gitolite would have looked after for
>> us).
>>
> i don't quite get what you mean. are gitolite permissions mapped to the
> svn repository? i don't see why the same could not be based on gerrit
> settings.

No, Gitolite detects when it is dealing with a Subversion client and
invokes the appropriate Subversion server side components and then
ignores everything else (ie. it performs no access control handling,
other than that already done by SSH itself, which Gitolite assists in
managing conveniently).

To the best of my knowledge, the Git focused Gerrit does not support
this at all. Having two SSH servers (as Gerrit does everything itself)
on the same system is just asking for trouble and confusion.

>
>> - It would very likely require (potentially invasive) changes to our
>> current anongit system,
>>
> i don't think so.
>
>> and likely our existing Git hooks to a certain extent as well.
>>
> very minor changes.
>
> your other items are self-evident to the point that i won't waste time
> on replying to that. rtfm.

Regards,
Ben

> _______________________________________________
> Kde-scm-interest mailing list
> Kde-scm-interest at kde.org
> https://mail.kde.org/mailman/listinfo/kde-scm-interest