Sysadmin report on the modernization of our infrastructure
Milian Wolff
mail at milianw.de
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
proposal:
a) the scratch repo functionality not being present yet.
b) https://secure.phabricator.com/T4333 <-- 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 https://showoff.phab.io/
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
that?
- 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 projects.kde.org 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.
Bye
--
Milian Wolff
mail at milianw.de
http://milianw.de
More information about the kde-core-devel
mailing list