Eliminate "Bouncing" in Reviews

[Mamoru Tasaka]

Warren Togami wrote:
> Mamoru Tasaka wrote:
> 
>> Actually there are many cases in that the review got troubled
>> _after_ the bug was approved and the reviewer should have
>> a responsibility for the review request until the review process
>> ends (i.e. the bug is closed) completely IMO.
>>
>> Mamoru
>>
> 
> Could you point at specific examples?
> 
> Warren

Well, there are many cases. Anyway I suggest again that the
reviewer should check the review  to the end with
responsibility until the reviewer imports the package
successfully and closes the bug correctly.

And... it is obvious that the person who _mainly_ has
to take action after the review passed is the submitter,
isn't it? Moreover I think that setting assingee as
reviewer, which explicitly shows the person who reviewed
the bug, makes it easier to trace the reviewes
_afterwards_ by bugzilla query or some other methods.

----------------------------------------------------------
* In not a few cases some other fedora contributors (mainly
  sponsor members) point out the incompleteness of the
  reviews, and in a very rare case, the other contributor
  has to switch back from FE-ACCEPT to FE-REVIEW.

* Once the bug was closed successfully (or because the review
  was rejected with some reason), however another issue is
  found (or the reason the reviewer rejected the review is
  resolved) and the bug has to be reopened.

* A submitter got troubled when trying to importing a package
  by various reasons and asked the reviewer for a help
  (well, this frequently occurs especially for new contributors,
   i.e. a new contributor askes the reviewer, who is the sponsor
   of the submitter for a help).

* The package the reviewer accepted will not build successfully
  on buildsys and the package needs more fix. Some reasons are:
  - Both the submitter and reviewer uses FC6, FC-devel.
  - Both uses only i386 (this is usually), and it turns out the
    mockbuild fails on x86_64 or ppc.
  - Simply, the mockbuild for the package is not checked (note that
    currently mockbuild is not forced on the review with some
    reason)

* The submitter forgets to import the package or forgets to
  close the bug (this is not unusual!) and the reviewer has to
  ask the reviewer "what is going on?" and set NEEDINFO
  from the reviewer...

A rare case (but I experienced) is:
* The submitter accidentally(?) imports the different version
  of package, which leaves some issues the reviewer pointed out
  unfixed.

and .. I may have saw some other issues...