[RFC] Solution for duplicated or false review/bug notifications
Luigi Toscano
luigi.toscano at tiscali.it
Fri Nov 2 23:54:00 GMT 2012
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?
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.
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.
Ciao
--
Luigi
More information about the kde-core-devel
mailing list