Another proposal for modernization of our infrastructure
thomas.luebking at gmail.com
Sat Jan 31 21:09:36 GMT 2015
On Samstag, 31. Januar 2015 20:37:31 CEST, Christoph Feck wrote:
> On Saturday 31 January 2015 20:07:42 Eike Hein wrote:
>> [...] Qt is using gerrit and we intend to remain a major stakeholde
>> in Qt development, which means a sizable number of KDE developers
>> need to be familiar with gerrit anyway [...]
> Excuse me, but if KDE developers will have to follow equivalent steps
> as described at http://qt-project.org/wiki/Setting-up-Gerrit to
> contribute, then I predict another big loss of developers.
Aside that this is an exhaustive HowTo on git and gerrit*, there're apparently "upload your plain diff" webfrontends.
(Though I think the question was brought up and not answered how follow-up patches are handled - eg. whether you've to pass some existing gerrit url to fetch the change-id from)
Gerrit is however very git-centric, so if you managed the git challenge, there's relly no additional complexity (and that includes things to learn. Messy repo/branch setups are messy).
If you however did WAAAAHHHHHHHH!!! GIT!!! (and I was close to that twice or thrice when KDE moved svn -> git) - you're indeed lost (resp. have to follow a very cumbersome patch upload path that kills all user-side gerrit benefits at once)
* Setting up git, with creating an account, uploading a key and configuring git certainly /is/ a one-time job you've to fulfill, but it's git, resp. actually scm related, not gerrit related.
The only** gerrit overhead here was really to dowload the change-id injecting hook.
**Though the demo setup also required to add a second repo, but that's hardly the case if gerrit would do the entire scm instead of being replicated to the git.kde repo that I originally fetched the code from (and because that's also been a clone, I actually have three repos there ;-)
More information about the kde-core-devel