Another proposal for modernization of our infrastructure
hein at kde.org
Sat Jan 31 19:07:42 GMT 2015
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
* 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.
More information about the kde-core-devel