[Kde-pim] Re: Problems with infrastructure

Thomas Lübking thomas.luebking at gmail.com
Thu Dec 11 12:24:27 GMT 2014


On Donnerstag, 11. Dezember 2014 09:13:23 CEST, Ivan Čukić wrote:
>> Yyou need to setup git correctly, so that "gerrit" in that command is
>>> valid,
>>> 
>> 
>> I see what you're saying, and you're probably right -- there's a bar,
>> indeed. That bar could however be effectively removed by having a
>> spoonfeeding,
>> 
>
> An alternative to the setup documentation is to actually do it
> automatically. A tool like kdesrc-build could set up the proper remotes
> when checking out a project.

I assume that Jan and Albert are talking about different scopes here.

If you're a regular comitter to a project or want to add a feature patch, consisting of several commits and lasting weeks until finished, you'll have to use git (properly) and the *additional* barrier to use gerrit is quite neglectable ("git remote add gerrit <url>") and the benefit of gerrit (enforces proper git usage, "git push gerrit HEAD:refs/for/master" is from my personal experience superior to rbtools, where my only attempt ended in a disaster ;-) notable.

Otoh, Albert seems to think of patches like "typo", "i think this should be <=" or "this loop does not exit in all conditions".

For such things
1. cloning a repo
2. figuring how to add a remote (and which)
3. fixing the issue
4. commiting
5. pushing
will fail to my personal lazyness on step 1 already. I'd rather lookup the author and send him a mail (if this item actually bugs me)
I would actually not even want to use RB for this either and I can very much assume that "*sigh*, git" contributers (git is actually great, but it /has/ a steep learning curve) are not willing to go for 2,4 & 5 (or feel uncomfortable/unsure when comitting/pushing)

Ideally™, one could just annotate the sources in quickgit (where one probably looked up the code) and trigger a "review request" (of whatever kind) this way.

Cheers,
Thomas

PS:
I don't like all things about the current gerrit webfrontend (notably the "open issue" handling after partial fixes), but that's no conceptual blocker from my pov.




More information about the kde-core-devel mailing list