Another proposal for modernization of our infrastructure

Jan Kundr√°t jkt at
Sat Jan 31 21:41:36 GMT 2015

On Saturday, 31 January 2015 21:38:23 CEST, Inge Wallin wrote:
> It is one thing if there is one tool that is totally too weak to work for 
> experienced people and one tool that is awesome but very 
> difficult to learn.  
> But that's not the situation we have here.  I think we have one 
> tool that is 
> very good and then one that many have pointed out as cumbersome 
> and difficult to 
> learn for not very experienced people - but - with an edge when it comes to 
> advanced git users.

I am a bit surprised to read that Phabricator is apparently considered 
"very good" even though no KDE project has tried it yet. I was under the 
impression that the usual order of steps is:

1) install a tool,
2) play with it,
3) identify its strenghts and weeknesses,
4) make an informed opinion.

Did I miss something? Which KDE project has been testing Phabricator?

> I know how long it took for me to get used ot git, and I think I'm pretty 
> experienced. Adding to that burden is not the way to get new people.

I'll repeat my request from earlier in this thread -- please quantify the 
expected increase of the barrier to entry. "Different" does not imply 

In Trojita, we have GCI students submitting patches wihin 15 minutes, 
following the developer-oriented newbie-unfriendly documentation. 15 
minutes for a high-schooler to start contributing. Translators have sent 
patches via Gerrit as well. Interestingly enough, the only complaint was 
from an experienced KDE developer, not from a newcomer.

Maybe the newcomers just do not care whether they're learning about 
Phabricator, Reviewboard or Gerrit.

Anyway, I don't really see a problem with the following steps:

0) Ignore any documentation, especially the "clone" command which already 
includes getting the hook. I don't read no documentation.
1) git clone ...
2) make changes && make && run
3) git commit -a
4) git push
5) Damn, that stupid Gerrit tells me on a command line that I should push 
to refs/for/master instead of just master. Oh well, stupid crap.
6) git push origin refs/for/master
7) Damn, now that stupid Gerrit tells me that I am supposed to copy-paste 
this line into my terminal for some crazy hook or what not, and to amend my 
commits. Annoying crap!
8) (copy-paste a line from Gerrit's output)
9) git commit --amend
10) git push origin refs/for/master

For those who actually read the documentation, it's of course more 
straighforward, but we all know that nobody reads documentation, hence the 
extra detours.

Besides, it has been already established that there will be support for 
direct patch upload.

> It would be very interesting to hear the VDG people's and the 
> translators' and documentors' view on this.

Given that the translators still use SVN, I sincerely hope that the 
proposed outcome does not involve us switching back to Subversion, or 
reducing our use of Git to an SVN equivalent.


Trojit√°, a fast Qt IMAP e-mail client --

More information about the kde-core-devel mailing list