Sysadmin report on the modernization of our infrastructure

Ben Cooksley bcooksley at kde.org
Tue Jan 27 08:51:46 GMT 2015


On Tue, Jan 27, 2015 at 3:30 PM, Thomas L├╝bking
<thomas.luebking at gmail.com> wrote:
> On Samstag, 24. Januar 2015 15:24:28 CET, Thomas Friedrichsmeier wrote:
>
>> But beyond review functionality, I think moving towards a more
>> integrated solution is clearly a step in the right direction, and this
>> is what makes the choice of Phabricator over Gerrit a clear case to me.
>
>
> I assume we all agree in wanting to have a more integrated solution than the
> status quo (which is basically not integrated at all), but keep in mind that
> "integration" does not require a "vendor lock-in", eg. not two items in my
> HiFi system are from the same vendor.

Agreed and agreed.

>
> A fully integrated pre-solution might look nice on a glimpse, but the
> pre-integration does not necessarily compensate for defects in the
> components.
>
> So far, this entire thread has actually only ever addressed the review
> process or maybe SCM entirely (unless I missed something) and the
> pre-integration has been brought up as a benefit (and from sysadming POV, I
> do certainly understand why), but I wonder whether the other required
> components have been checked for feature completeness.
>
> Eg. I do not see the Phabricator Task tracker approach to be fundamentally
> different from (read: "superior to") bugzilla (notably the comments seem to
> be just as linear and there also does not seem to be a "summary" comment to
> be edited by maintainers anytime - two things I would actually like in a
You can't really compare Jenkins with Zuul as they're designed to
achieve different goals.

Jenkins provides rich tracking of tests, code coverage and code
quality (eg: cppcheck) in addition to checking if it builds.
Zuul is designed to determine if it builds and if tests fail -
providing a binary pass/fail response.
Harbormaster at this point at least looks like it will be similar in
nature to Zuul.

I'll also note that Jenkins provides scheduling and can bring nodes up
and down as needed (when equipped with access to a cloud/cluster).
For this reason Openstack is still relying on Jenkins in part as Zuul
can't do this.

Jenkins also permits us to track jobs unrelated to our code reviews,
which is necessary for
Hmm? It has a description section on tasks. See
https://secure.phabricator.com/T1315 for an example.
This can also be freely edited.

I'm not aware of any threaded discussion issue tracker, but i'm happy
to be corrected.

> bugtracker), but even a short research suggested it neither does suggest
> duplicates, not is there intention to add such.

It is mainly intended as a task tracker rather than a bug tracker I
believe, hence this position.
The more suitable item to compare it to would therefore be todo.kde.org.

> To me, this raises the question whether it's actually capable (or will ever
> be) of replacing (let alone "surpassing") the current bugzilla solution.
>
> For another example (and vastly discussed) the integrated CI is "when it's
> done", nobody has actually seen it in process, so we might end up with the
> patched-on Jenkins forever.
>
> Also the definitive blocker of scratching on-behalf-commit meta-info (for
> the SCM) has been brought up.
>
> I'm not familiar enough with either Jenkins nor Zuul to say which one's
> "better" and I cannot judge about the Phabricator bugtracker feature
> completeness, but if we end up with having to use external components
> because the pre-integrated ones do not fit our requirements (for an
> undefined time), the pre-integration argument is simply void.

I concur here that pre-integration is void if the pre-integrated
components aren't useful.

>
>
> Bottom line is:
> ---------------
> When you can well integrate the things you like, that's not necessarily
> inferior to some pre-integrated solution.
>
> And to asset the advance of the pre-integrated solution, that solution has
> to be evaluated in its completeness - as one has to presume that it might be
> much harder to replace components of a solution that is meant to run en
> bloc, than it would be to plug together components which provide a public
> API for that very designed purpose.

For those that are worried - people have integrated JIRA and
Phabricator together, so it is more than possible to connect
Phabricator with external task trackers.

Please recall that no change of bug tracker or CI system is being
planned at this time - such a change would be for future discussion.

>
> Cheers,
> Thomas

Thanks,
Ben




More information about the kde-core-devel mailing list