Task #3770
open
Set up a TDF cgit instance
Added by Aron Budea 4 months ago.
Updated 4 months ago.
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
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.
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?
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
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.
Also available in: Atom
PDF