Sysadmin report on the modernization of our infrastructure

Milian Wolff mail at
Wed Jan 21 14:33:32 GMT 2015

On Wednesday 21 January 2015 17:12:07 Ben Cooksley wrote:
> Hi all,
> As promised in the earlier thread, i'd like to present the sysadmin
> report on the state of the infrastructure surrounding our code.
> It contains a detailed summary of what is broken with our existing
> systems, why change is necessary and an evaluation of the options we
> considered. We have also made a proposal based on our evaluations and
> the wishlist of functionality drawn up the community.
> Please find it attached - and let us know what you think. Feedback is
> welcome.

Hello Ben,

thanks for this thorough explanation, it fills in quite some gaps that I was 
not aware of.

Phabricator does look interesting, and I'd be willing to experiment with it as 
well. But, and this is a big but, there are some issues I have with the 

a) the scratch repo functionality not being present yet.
b) <-- this is a serious blocker

Does this mean we will wait until upstream has this implemented before we 
start moving KDE? I'd dislike doing a move, or even a test-run, before all 
required functionality exists.

For those who want to try out Phabricator, I found

Furthermore, some open questions from my side, regarding Phabricator:

- is it really trivial to implement commit hooks, such as closing bugs in 
bugzilla, with herald? With the demo above, it is not clear how to do this. I 
can only "Block Change With Message" in a commit filter.
- is it possible, and if so - how easy is it, to add bots to the review 
system? i.e. something like a nitpicker bot similar to the Qt Sanity Bot. The 
herald demo above does not seem to support running scripts which go beyond the 
simple point-and-click GUI.
- Could, eventually, our CI be integrated? Such that, when a change is landed 
which breaks the build, it's automatically reverted and/or a comment added to 
the review page? There seems to be a "build plan" for phabricator - what is 
- will reviews be enforced, or will they stay opt-in as we have it in the 
current KDE workflow?
- again a herald-related question: will the IRC bots continue to work which 
announce new commits?
- is there still an ATOM/RSS feed of commits? I could not find that in the 
phabricator demo (note: must work without prior login)
- can "common" herald rules be offered to users to save them some work? I.e. a 
simple button to get an email for every "kdevelop" or "frameworks" or "kdepim" 
or ... related review/commit/issue/... the more git repos we add, the bigger 
this issue becomes
- you said required custom patches, e.g. for adding support 
for selecting the i18n branches. how is this going to be different in 
Phabricator? what existing functionality there will supplement this, thereby 
obsoleting custom patches?
- you also mentioned the issues around Gitolite metadata generation, 
kde_projects.xml etc. - how will Phabricator address these issues?

Overall, I'd welcome if a simple dummy phabricator instance could be set up 
such that we all can play around with the features it provides, including 
pushing changes and trying out arc.

Milian Wolff
mail at

More information about the kde-core-devel mailing list