FYI: Status of gdb usage of gerrit

[Jonathan Nieder]

Florian Weimer wrote:
> * Jonathan Nieder:
> > Florian Weimer wrote:

>>> I think this dual setup is too confusing.  People will ack patches on
>>> one side of the fence that have been vetoed on the other side.
>>
>> I guess I'm confused about the problem you're describing here.  Gerrit
>> allows pushing changes without review if configured to do so (and will
>> do the right thing to close the review by looking up its Change-Id,
>> etc), so why would we want to be bypassing Gerrit instead of doing
>> that?
>
> I'm confused.  Is this question in response to what I wrote, or to
> what was discussed elsewhere in the thread?

Ah, I didn't understand what you meant by the dual setup.  The
clarification below helped.

>> Instead, we seem to be evaluating this initial experiment as though it
>> is all that Gerrit has to offer.
>
> I don't think Gerrit offers anything comparable to what Patchwork
> does, so the issue I raised in the quote above will persist because
> the mailing list discussion has to be reviewed on the mailing list.
> I'm not sure if a review tool whose state reports you can't trust is
> all that useful.  I think if we want to use Gerrit, we would have to
> require that objections to Gerrit-managed changes would have to be
> recorded in Gerrit.

I see.  Is this mostly about Gerrit's email ingestion skipping patches
it doesn't understand?  I.e. if https://crbug.com/gerrit/8904 (using
References in reply handling) and https://crbug.com/gerrit/11842
(making the fallback behavior in email parsing be to make a change
comment instead of rejecting the message) were fixed, would that make
Gerrit's state reports trustworthy?

> Regarding the larger issue of configuration, I'm aware that we have
> barely scratched the surface.  However, we do not have a dedicated
> process engineering team that could work out what we need.  To me,
> this suggests that we are largely stuck with what's available out of
> the box.  (Even finding someone who would host Gerrit for us turns out
> to be difficult.)

*nod* Sure, I understand that.  That said, I suspect that when it
comes to that, upstream (repo-discuss@googlegroups.com) would be
willing to help.

What I really mean is that we should take the opportunity to learn
from this and other experiments by defining our requirements.  In the
end, we'd have a better sense of what we need and could then revisit
which tool is best at providing that or whether we need to implement a
new tool.

Thanks,
Jonathan