[RFC] Solution for duplicated or false review/bug notifications

[Jarosław Staniek]

Luigi Toscano wrote:

> Jaroslaw Staniek wrote:
>> tl;dr
>> I propose to treat public KDE git branches (for all repos) having
>> '-work' suffix in a special way: ignore REVIEW and BUG/CCBUG lines.
>> When commit hits a public KDE git branch without -work suffix, current
>> behaviour is preserved.
>> 
>> ** The problem:
>> Whenever commits are pushed from work branches and they contain
>> merged/cherry-picked commits (from other developers) with REVIEW:
>> line, we're getting repeating notes on rb and emails: "This review has
>> been submitted with commit xxxxxxxxx by yyyyyyyy to branch zzzzz."
>> I think the hook shall not generate duplicated reviews like this.
> 
>> [...]
>> **What workflow is affected:
>> Affected workflow that use integration with git.reviewboard.kde.org
>> and/or bugs.kde.org is as follows:
>> 
>> 1. Push a change without a REVIEW but optionally with BUG/CCBUG lines.
>>     Of course because we do not know the review number at the moment).
>> Pushing to a public work branch is often needed if we expect someone
>> will need/want to test the code.
> 
> 
> So why not using a personal clone for this (publishing the work), and not
> allowing notifications (if it is not the case) for personal clones,
> instead of changing the rules for official repositories?

It's possible but while personal repos are useful, let's see what is
introduced with them in our context:

- for reviewboard I need to reference public project's repository, e.g. 
calligra; otherwise patches will get rejected reviewboard; so before 
submitting to review I need to create a copy of the commit within the 
official repo anyway

- private repo adds another layer in the (already not trivial to explain) 
multiuser workflow: I need to create a copy of the commit in the official 
repo anyway since the personal repo is meant for use (r/w) by the owner (if 
I understand correctly)

- private repos do not support email notification about the changes (hiding 
them was not requested by me)

> Rebase on officially published repository is always bad. I don't think
> officially allowing rebase on a subset (the -work ones) of public branches
> is the proper way to do.

This is not a part of the request. It's about behaviour of integration with 
rb and b.k.o, i.e. KDE-specific integration. When using cherry-picking.

> For cherry-picking, there is not so much to do, as they are new commits.
> Merged commits (not rebased), afaik, do not produce new notifications.

That's true. Our discussion is based on the assumption that cherry-picking 
is valuable just like editing commits before picking them to other branches 
(e.g. split/squash) is. I am askimg my 'students' to commit early and often 
without a fear to their -work branches.

Author of git explains it's jsut another tool which complements merges 
[https://lkml.org/lkml/2008/5/21/351].
But then multiple messages that contain the same REVIEW or BUG lines will 
exist in the repo, when some of them do not mean a review is submitted or a 
bug is resolved. So here's the proposal for addressing this (when needed) in 
advance - when picking a name for a new branch.

There's different solution that addresses the problem of duplicated 
submissions (but not the unwanted premature submissions):
It may be possible to block 'resolving' of already 'resolved' bug on b.k.o 
and submitting already 'submitted' review on rb by altering logics of these 
two sites. 

--
regards / pozdrawiam, Jaroslaw Staniek
 Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org
 Qt Certified Specialist | http://qt-project.org
 http://www.linkedin.com/in/jstaniek