Project

General

Profile

Actions

Task #3770

open

Set up a TDF cgit instance

Added by Aron Budea 2 months ago. Updated 2 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Tags:

Description

A big benefit of cgit.freedesktop.org [1] was/is that it provides a fairly easy-to-read diff of the files, see eg. the following random commit for comparison:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=8ab44b114c6706ab2e3d8a19884daeb544d3c2e1
vs.
https://git.libreoffice.org/core/commit/8ab44b114c6706ab2e3d8a19884daeb544d3c2e1

The gerrit view tries to highlight changes within lines as well, which IMO makes it a bit more confusing, and the colors aren't the best, either (green could be darker, and the highlights lack contrast).

Not to mention the confusing tree view, the above URL expands to the following (with a ^! at the end):
https://git.libreoffice.org/core/+/8ab44b114c6706ab2e3d8a19884daeb544d3c2e1%5E%21/
If you omit the ^!, you can get to two different views:
https://git.libreoffice.org/core/+/8ab44b114c6706ab2e3d8a19884daeb544d3c2e1/
and
https://git.libreoffice.org/core/+/8ab44b114c6706ab2e3d8a19884daeb544d3c2e1
Both can be confusing if you just try to substitute a new hash in the URL, and aren't familiar with the syntax.

I still use cgit URL in the bugzilla myself, but the cgit freedesktop instance is being unreliable lately (as mentioned in [2] as well), and who knows when it is shut down for good.
I propose setting up a cgit instance at TDF, so people can pick which way they prefer viewing and referencing commits online. It probably wouldn't be hard to set up and maintain.

[1] https://cgit.freedesktop.org/libreoffice/core/
[2] https://redmine.documentfoundation.org/issues/3769

Actions #1

Updated by Guilhem Moulin 2 months ago

Aron Budea wrote:

I propose setting up a cgit instance at TDF, so people can pick which way they prefer viewing and referencing commits online.

As the (likely) maintainer, I want to push back on that. The focus should be on consolidating existing systems, not further dilution and maintenance burden.

Actions #2

Updated by Aron Budea 2 months ago

Guilhem Moulin wrote in #note-1:

As the (likely) maintainer, I want to push back on that. The focus should be on consolidating existing systems, not further dilution and maintenance burden.

That is understandable.

The options I see are the following:
1. Set up a system at TDF, with maintenance burden at TDF,
2. Keep a system at an external entity, with maintenance burden at them, including the current reliability issues, and the likely eventual shutdown of the service,
3. Get used to the UX deficiencies of Gerrit git view,
4. Improve Gerrit's UX.

If neither 1, 2 or 3 is desired, that leaves us with option 4. Is that a more feasible option?

Actions #3

Updated by Guilhem Moulin 2 months ago

Depend on said improvements :-) Right now we're not running a custom gerrit instance, and I'm a tad reluctant to go that route for a such a mission-critical core component. However by “Gerrit UX” I assume you mean its git browser component (plugin), which you linked to above. We are running a patched version [0] of that component and while upstreaming changes is of course preferable, I see no issue with adding further patches as long as they are reasonably maintainable and not too intrusive. (I added for instance support for the inline diff you mentioned, because some devs requested it at some point.) Tweaking colors, in particular, is a no-brainer (CSS patch welcome).

[0] https://git.libreoffice.org/infra/gitiles/history/e80469094f135b514db2420eb621383505b84bf6

Actions #4

Updated by Guilhem Moulin 2 months ago

while upstreaming changes is of course preferable, I see no issue with adding further patches as long as they are reasonably maintainable and not too intrusive.

To expand a bit on this, non-trivial/cosmetic custom patches cause an obvious potential maintenance burden when upgrading gerrit core. But this doesn't apply to micro-versions (security updates an other important bug fixes), which are the only ones we need to follow carefully and apply ASAP. Gerrit upstream maintains 3 major versions at the same time and have a documented release schedule, so in practice major upgrades can be deferred. Also we have a stage instance for tests and development.

Also we've been through 8 major gerrit releases since the introduction of our custom patches, and IIRC only one (3.6 → 3.7) required a major overhaul/rebase. There is no guaranty that they won't cause more pain in the future, but in practice it has been manageable so far.

Actions

Also available in: Atom PDF