Sysadmin report on the modernization of our infrastructure

[Thomas Friedrichsmeier]

Hi,

On Tue, 27 Jan 2015 03:30:48 +0100
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.

I think vendor lock-in is just the wrong term, here. It's not like it's
not possible to keep using bugzilla with phabricator, for instance.
It's just that you don't get some integration features, or only at
considerably more effort. Arguably, at this level, "nothing" has kept
us from achieving similar integration with the current setup.

> A fully integrated pre-solution might look nice on a glimpse, but the 
> pre-integration does not necessarily compensate for defects in the 
> components.

Naturally. And clearly a "pick tool A from X, B from Y"-kind of
approach will - at least on paper - allow to satisfy more wishes.
Unless you take integration and maintenance effort into account. (Which
is still not actually saying that Gerrit would be the solution to
satisfy "all wishes" in the review department; clearly there are
"defects" of debatable severity to be found in this solution, too).

> 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.

Ideally that would be done in much more detail, true. There does seem
to be a certain level of impatience about actually starting to move in
some direction, though (and that may make a lot of sense). So the
options are
1. spend some more months on open evaluation and testing
2. commit to solution X (barring "real" blockers to be discovered), and
deal with issues as they come up
3. split the problem into smaller portions, by looking at one tool at a
time. Sounds good on paper, but - again - adds unnecessary prejudice
against any integrated solution.

> 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.

Well, as far as I see it, the key points of "superiority" would be:
- automatic cross-linking with review requests and tasks
- cross-linking with project(s) (and actually, lack of this is the
  number one issue that keeps driving me mad with b.k.o, and its
  drop-down list of one-gazillion projects+subcomponents)
I.e., once again: Not fundamentally different, but integrated.

Regarding the dupes issue, the comment you refer to, is the developer's
explanation, why the feature does not currently exist. The issue
also has a patch for review.

Regarding the summary comment: It's called "description", in
phabricator.

> 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.

A risk sysadmins seem willing to take.

> Also the definitive blocker of scratching on-behalf-commit meta-info
> (for the SCM) has been brought up.

To be honest, I think terms like "definite blocker" should be used with
more care (on both sides of the argument, of course). Esp. as this is
not available in reviewboard, either (for all I am aware), and there is
a workaround available (requiring three
commands instead of one).

Bad: yes. Blocker: Come on, now.

> 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.

True. And I can't give you answers to all your questions, either. But I
actually do trust that sysadmins that done the _basic_ checking well
enough.

> 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.

My bottom line: Potentially integrated is just not the same thing as
pre-integrated. Discarding the pre-integrated solution, because you have
not yet managed to evaluate all features and defects of all potentially
interesting components, is not going anywhere.

I also don't think your presumption holds water. At least for the
review-component (the one we're talking about, initially), an API
clearly exists. Further, upgrading parts or all of a manually integrated
solution might be much harder than upgrading a pre-integrated solution.

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20150127/7a825da3/attachment.sig>