Am 12.03.2012 09:55, schrieb Mathias Krause:
For me the annoying thing is that gerrit is not fully integrated into the mailing list and vice versa, too. Review done on the gerrit web page is not mirrored to the mailing list and reviews done on the mailing list gerrit will not be aware of. So it would be nice to see the reviews done on the gerrit web page as emails on a mailing list, too.
That would require covering the other route (mail to gerrit) as well, which quickly gets ugly (mail is unstructured data).
gerrit is not a mailing list frontend - we had that with patchwork and it didn't work for us.
Another point, already mentioned, would be to give those "patch set updated" emails some more value. When I push an update to git, gerrit already tells me what has changed (i.e., only rebased or subject changed or files, too). It would be nice to at least get this information from the gerrit web site and from the emails, too; interdiff would be a bonus.
Smarter diff handling would be nice, yes. There are some clues that it might be worked on in gerrit, but nothing definite.
Non-updates, i.e. unchanged commits of a series, should have no effect at all - no email, no new patch set. It just "destroys" previous reviews. But I guess this would require some changes to the gerrit code base?!
Skipping emails for non-changes might work. Even now, though that would require some manual postprocessing with interdiff to see if there are any relevant changes. It definitely would be easier if interdiff-like functionality ends up in gerrit.
Skipping creation of patch sets breaks the mapping of gerrit patch sets to git commits. Right now, every gerrit "patchset" can be uniquely identified in the repository.
Once there are multiple git commits (and those change all the time for the tiniest reasons in the metadata, eg. commit date, which is different from the visible date), we'd lose this.
Patrick