Setup non-pushing gerrit instance for glibc.

[Simon Marchi]

On 2019-10-25 12:10 p.m., Joseph Myers wrote:
>>> There is a difference of *intent* between changes that depend on one 
>>> another and a patch series.  A patch series is saying:
>>>
>>> * there is a common purpose motivating the patches; and
>>
>> In Gerrit, you'd probably use topics to indicate that many changes have
>> a common purpose (whether they are interdependent or not).
>>
>> https://gerrit-review.googlesource.com/Documentation/intro-user.html#topics
> 
> If using a topic were to mark the patches as a patch series (including 
> marking email subjects and threading them accordingly), that would be 
> fine.  I don't think it's necessary for simply pushing multiple changes at 
> once to be the way you cause something to be handled as a patch series, if 
> topics are the idiomatic concept in gerrit that corresponds to a patch 
> series as generated by git-format-patch.

I don't believe the topic is included in the email (at least not the subject),
but that is likely possible to do.  For example, including it in the prefix tag:

  [review my-topic-name]

I think that would help, but we would still be missing the information about
the order of the patches.  Any ideas for that?

>>> There's also the variant of patch series that are explained in the cover 
>>> letter (or in other text not intended for the final commit) as being split 
>>> only for review purposes and intended to be squashed for commit, if the 
>>> pieces most convenient for review don't form bisectable commits.  I'm not 
>>> sure how much any review system needs to know about the distinction 
>>> between the two kinds of patch series if it's not pushing the commits 
>>> itself.
>>
>> I don't think there would be a problem with that, except that the two emails
>> on the mailing would not be threaded together.  More thoughts about that
>> below.
> 
> Well, there would be issues if you wanted gerrit to push changes itself.  
> And how does the "identify this as being the same change" system (for 
> knowing when something has been committed) work if multiple separately 
> reviewed patches are squashed into one commit?

In that case, I would keep in the squashed commit the Change-Id of the first
commit (i.e. the commit that contains the logical change, not the generated
stuff).  When pushing that commit, it will auto-close the first change.  The
last/final version of that change would therefore be the full thing, including
the generated stuff.

I would then need to abandon the second commit.  In the reason field (when you
click Abandon) I would say that since the content has been squashed in the
parent change, which is now merged, this one is no longer needed.

> (Is the valid syntax for Change-Ids documented anywhere?  In particular, 
> is it OK to write a human-readable Change-Id oneself?)

It's not mentioned here [1] so I suppose it's not documented.  We would have
to look in the source code (or just try it) to see what's supported.

[1] https://gerrit-review.googlesource.com/Documentation/user-changeid.html

Simon