This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Setup non-pushing gerrit instance for glibc.
Hi,
A few quick notes from an ex Gerrit developer (nowadays almost all my
time is devoted to Git instead).
Joseph Myers wrote:
> Observations on teething troubles with the initial setup:
>
> 1. What's the status of fixing the problem with insufficient diff context
> in emails when comments relate to particular parts of the diff?
A quick search doesn't find a bug open about this at
https://crbug.com/gerrit/new.
[...]
> 2. Could text comments in emails from gerrit be properly wrapped?
> Messages such as
> <https://sourceware.org/ml/libc-alpha/2019-10/msg00715.html> are hard to
> read in the list archives because of very long lines. (Of course, diff
> context / quoted source lines should not be wrapped.)
Makes sense. Likewise, I don't see an existing bug open for this.
> 4. Could we document how to get and keep up to date a complete local copy
> of all the glibc review data in gerrit (comments etc.) using whatever APIs
> are available?
"git clone --mirror" would do this --- the code for the 5th iteration
of change #1234 is at refs/changes/34/1234/5, and the metadata (review
comments, etc) is at refs/changes/34/1234/meta.
See https://gerrit-review.googlesource.com/Documentation/concept-refs-for-namespace.html
and https://gerrit-review.googlesource.com/Documentation/user-upload.html#_gritty_details
for more on this subject.
Alternatively you can do something with
https://gerrit-review.googlesource.com/Documentation/rest-api-changes.html,
but that sounds fussier.
[...]
> 5. It would also be useful to have documentation for how someone should
> make a patch series appear appropriately in gerrit if they want to propose
> a series that way. That means the emails for a patch series should
> include 1/N, 2/N etc. in their subjects (with a 0/N cover letter as
> appropriate).
I really like this idea. Feel free to file a feature request for it
at https://crbug.com/gerrit/new.
> 6. Lower priority, but note there are certain kinds of changes involving
> huge diffs (e.g. to generated files) that thus *would* need a message size
> limit and pointing to a URL for the diffs in that case, for it to be
> possible to handle such changes through gerrit.
The default behavior is to limit diffs to 256k:
https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#sendemail.maximumDiffSize
Thanks,
Jonathan