Another proposal for modernization of our infrastructure

[Eike Hein]

On 01/31/2015 10:37 AM, Jan Kundrát wrote:
> About the "we could" vs. "we will" in general, I have to admit I'm
> slightly confused by that. The proposal is careful to describe what is
> available today, and to make a clear difference in saying what needs to
> be done in future. Maybe some part needs clarification -- what parts do
> you think are more of the yes-this-would-be-nice-but-I'm-worried nature?

I just wanted to make the point (but I agree I made it a bit
poorly) that it's worth differentiating between features the
proposed solutions are guaranteed to deliver right away, and
features they may enable in the future, but only if certain
other conditions are met, e.g. raw infrastructure expansion.

That's not a knock against your proposal, though - it's much
easier to e.g. ask for hardware donations when you can point
to a clearly identifyable need.

--- snip ---

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.

* 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.


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.

* 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.

Given all of this, I find it really hard to have a firm
opinion at this point. Both proposals promise strong
benefits to different aspects of what the community is
doing, which makes this an exercise in weighing those
aspects and predicting future outcomes based on different
ratios between them.

That said, at this point, I have more experience work-
ing with gerrit than with Phabricator, and I think that's
something that needs to be addressed as part of this
process. I think we should proceed with setting up a test
instance and giving it a spin, this should help with
getting things into clearer focus.


Cheers,
Eike