Another proposal for modernization of our infrastructure

[Inge Wallin]

On Saturday, January 31, 2015 20:07:42 Eike Hein wrote:
> On 01/31/2015 10:37 AM, Jan Kundrát wrote:

> I'd like to summarize my current feelings on both proposals.
> 
> 
> Here's what I think gerrit's strong points are:
> 
> * There's undeniably synergy and cultural alignment with
>    middleware communities we depend on to be had. Qt is
>    using gerrit and we intend to remain a major stakeholder
>    in Qt development, which means a sizable number of KDE
>    developers need to be familiar with gerrit anyway. KDE
>    using gerrit lowers the barrier for KDE developers to
>    work upstream, and for folks in the wider Qt community
>    to involve themselves in KDE. Particularly for Frame-
>    works development this could be a boon.

Aside from the point that Christopher made that a too strictly restricted 
workflow will drive developers away, I also think this point is overstressed.  
The problem is not the developers that are good enough to actually contribute 
to Qt.  The problem is the new people that will never stay around if they have 
to too much to learn until they can make their first contribution.

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 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'd like to liken this with myself as an emacs user.  I have so far not seen 
one feature in any visual development environment that is not also available 
as a plugin feature for emacs. Emacs simply has a superset of all the features 
of all the other integrated devtools out there - but - it does it without 
graphics and with keyboard shortcuts. It's not without reason that emacs has 
sometimes been interpreted as escape-meta-alt-control-shift. :)

Despite all this awesomeness, I have a hard time convincing people to use 
emacs. And why? Because it has a steep learning curve. So if I were to force 
people to use emacs they would run for the hills. I think I could outedit 
almost anybody when it comes to pure editing text files whatever the task.  
This is due to the sheer size of the emacs toolbox coupled with extreme 
versatility of the tools themselves.  

But this is not what makes people productive with development. Editing is but 
one of the many steps we have to do when developing our KDE applications. And 
it's the same way with patch review. Even if a complicated tool would make the 
top people's job easier, the cost to the community would be too great if we 
were to force this tool on everybody. So with the current choices I from now 
on will support Phabricator as the choice of the community.

Caveat:
The above choice is only valid if Phabricator is actually up to the task. I 
guess the tests will tell us this.

> * gerrit and the community around gerrit (which includes
>    Jan) appears to have considerable chops when it comes
>    to solving hard infrastructure problems like advanced
>    CI and replication. This is stuff that can enhance the
>    quality of our products by improving our processes,
>    but it also stands to make KDE a more attractive envi-
>    ronment for incubating new projects. Infrastructure
>    should not be the sole platform we run recruitment on,
>    but staying competitive is important, and one way to
>    do that is to try and lift things only a community of
>    KDE's size can lift -- and that can e.g. include
>    gathering donations for fancy CI cluster setups. 

...provided we will have any new people that can execute those processes.  :)
I'm still unconvinced that gerrit is the tool to grow our community.
 
> Here's what I think Phabricator's strong point is:
> 
> * From what I've seen and played with so far, I really
>    like the UI. This is a short bullet, but an important
>    one.
> 
> * In terms of cultural alignment, I see communities like
>    Blender and Wikimedia pick Phabricator. Lowering the
>    barrier for cross-pollination with communities like
>    this seems very attractive to me, because there's
>    types of talent engaged in those communities that we
>    need more of in KDE, e.g. designers and artists.

This is a good point that I actually didn't consider before.  How does e.g. 
the Visual Design Group Work with review? Do they? And if not, would they if 
they had the proper tools?  And how do Gerrit and Phabricator stack up here?

> * I expect the above drivers to make it more likely that
>    Phabricator will develop functionality that will make
>    it more useful for these types of contributors. For
>    example, good diff viewers for visual assets, good
>    handling of screenshot attachments to change proposals,
>    etc. I feel like it is less likely that gerrit will
>    become similarly useful for non-code assets.
> 
> * The conflation of change review and issue tracking in
>    Phabricator makes sense in the above context as well,
>    and could greatly improve our non-programming develop-
>    ment processes. In short, I don't see gerrit benefit
>    our non-code contributors at all, but I see a shot at
>    Phabricator doing so.

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