Infrastructure » Websites

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.

cgit is pretty bad, both in implementation (C) and result. I know Gerrit very little, but I encourage you to report some of its issues, and sincerely hope that such a workaround is not needed.

With certificate demise of the FreeDesktop cgit instance this has kind of become more of an issue for QA efforts.

For those of us that don't build, nor maintain a git branch locally, cgit has been very useful to identify a range of commits with "SHA1..SHA2" log query syntax as a starting point for bibisecting an issue.

Don't know how much of a support tail it incurs, but doesn't the cgit structure come along with our gerrit tooling? And it needs only DNS record and enabling the server?

Feasible to get an instance configured, IHMO a cgit interface to gerrit/git would be helpful to the project.

vsfoote Foote wrote in #note-6:

For those of us that don't build, nor maintain a git branch locally, cgit has been very useful to identify a range of commits with "SHA1..SHA2" log query syntax as a starting point for bibisecting an issue.

Could you give an example of that syntax? I'd be surprised if gitiles didn't have something equivalent. For instance this is a shortlog of the last 10 commits on the master branch: https://git.libreoffice.org/core/history/27ee20b..f293b8a . And https://git.libreoffice.org/core/diff/27ee20b..f293b8a shows the diff between the same 10 commits.

doesn't the cgit structure come along with our gerrit tooling?

No it doesn't.

Feasible to get an instance configured, IHMO a cgit interface to gerrit/git would be helpful to the project.

I stand by wrote I wrote 2y ago. There is already a git web viewer at TDF

Default cgit web interface allows a drop list pick of the git branch to query, allowing a method to identify when and if a commit is present on that branch.

It also has a query type drop list query against "log message", "author", "committer", or "range"

The cgit web search by branch (e.g. master, or 25.8.7, or 24.2) and of a specific commit by message, or a range of git commit HASH (as taken from build head of a TB nightly or final TDF build) makes the cgit interface much more efficient than arcane command line git log or gerrit filter syntax. The suggested https://git.libreoffice.org/core/history/[SHA1..SHA2] does not differentiate the branch and seems to choke for a range with branches mixed.

So, even if a cgit web server is not delivered by default with a gerrit instance (though a quick web query still suggests it does) it seems like it still would be worth the effort to enable it.

It's not a only a matter of enabling it, but a commitment to maintain it on the long term. It's an external project not bundled with gerrit in any way (unlike gitiles), so there is a maintenance overhead. OpenStack, wikimedia, chromium and other gerrit projects use gitiles as git web viewer not cgit. Should also point out that the Github mirror seems to offer much of the functionality you're describing.

Guilhem Moulin wrote in #note-7:

vsfoote Foote wrote in #note-6:

For those of us that don't build, nor maintain a git branch locally, cgit has been very useful to identify a range of commits with "SHA1..SHA2" log query syntax as a starting point for bibisecting an issue.

Could you give an example of that syntax? I'd be surprised if gitiles didn't have something equivalent. For instance this is a shortlog of the last 10 commits on the master branch: https://git.libreoffice.org/core/history/27ee20b..f293b8a . And https://git.libreoffice.org/core/diff/27ee20b..f293b8a shows the diff between the same 10 commits.

Indeed, this is already documented here: https://wiki.documentfoundation.org/QA/Bibisect#Commit_ranges

We would be better off adding missing search functionality to Gitiles. One volunteer developer has already privately expressed interest in working on it.