[Development] Moving to Gerrit 2.16.9

[Frederik Gladhorn]

On fredag 28. juni 2019 17:29:29 CEST Mutz, Marc wrote:
> On 2019-06-27 16:10, Frederik Gladhorn wrote:
> [...]
> 
> > On a related note, now that things are generally working with the new
> > Gerrit,
> > I was wondering if we want to consider plugins. There is one to add
> > reviewers
> > based on git blame
> > https://gerrit-review.googlesource.com/admin/repos/plugins/reviewers-by-bl
> > ame and I'll give Gravatar a spin:
> > https://gerrit-review.googlesource.com/admin/repos/plugins/avatars-gravata
> > r
> > 
> > We should also consider the various webhooks plugins. Comments
> > appreciated.
> 
> I don't know whether there's a plugin for that, but a feature that would
> really benefit a lot of Qt devs would be if Gerrit would understand
> whether the Merge Conflict is due to a prerequisite commit not having
> been merged, yet, or whether there's really a conflicting commit merged.
> It kind of knows already, since it shows which other commits conflict
> with the current one, if any, but it still shows Merge Conflict for
> missing prerequisite commits. It would be totally cool if instead of
> Merge Conflict, it would show Prerequisite Missing (e.g.).
> 
> And then, going into dream mode, if one could add a prerequisite
> manually, across modules, so that a, say, qtdeclarative change could
> track a qtbase one and show Prerequisite Missing until the qtbase commit
> has been merged _and integrated_ in qt5.
> 
> Don't know how hard this would be to implement, or if it's possible at
> all.

I agree that merge commits are confusing. In general I'd say the dependency 
tracking is not always super clear in the new UI.

The merge conflict detection is part of Gerrit core, there are no plugins that 
go so deep as far as I know. Improving that should clearly be done upstream, 
in Gerrit core.

If anyone wants to contribute, this kind of improvement should be welcome.

Cheers,
Frederik

> 
> Thanks,
> Marc