Sysadmin report on the modernization of our infrastructure
inge at lysator.liu.se
Tue Jan 27 09:33:11 GMT 2015
On Tuesday, January 27, 2015 03:30:48 Thomas Lübking 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.
> A fully integrated pre-solution might look nice on a glimpse, but the
> pre-integration does not necessarily compensate for defects in the
> 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
> bugtracker), but even a short research suggested it neither does suggest
> duplicates, not is there intention to add such.
> 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.
And this is of course the reason why the sysadmins have asked for projects
that would volunteer as guinea pigs for the new system. And several have
volunteered so we might soon know.
> Bottom line is:
> When you can well integrate the things you like, that's not necessarily
> inferior to some pre-integrated solution.
Since one of the sysadmin's complaints of the competing solutions was that
they didn't well integrate without lots of hacks, I suggest using the wording
"If you can..." instead.
And I think that this is the point that has gotten lost in the discussion at
large. Gerrit may well be just as good as Phabricator or perhaps even better
at code review; I simply don't know. But for overall integration with the
rest of the infrastructure it's just one piece of the puzzle that needs to be
interfaced to - again.
The git hosting needs to be switched to something faster, the bug tracker
needs to be integrated, projects would like to have their own mini-websites
close to but not inside KDE. And so on.
Can we please put a little more emphasis on this part of the issues too?
> 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.
More information about the kde-core-devel