<div dir="ltr"><div>Hi<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 19, 2020 at 11:10 AM Frediano Ziglio <<a href="mailto:fziglio@redhat.com">fziglio@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> <br>
> Hi,<br>
>    the community around the SPICE project always tried to follow one<br>
> fundamental, implicit rule for accepting code contributions to the<br>
> project: every merge request (beside trivial patches) should be reviewed<br>
> and acked at least by one before getting merged.<br>
> While everyone agrees with this fundamental rule, the actual status of<br>
> some SPICE projects makes the rule impractical to let the project move<br>
> forward.<br>
> Let's consider the spice/spice project as an example: the number of<br>
> contributions is very low, both on the commit side (only 4 different<br>
> contributors with more than 1 commit from the beginning of the year, and<br>
> a single contributor with 90% of commits) and on the review side (in the<br>
> last 40 merge requests before the C++ switch one, 21 had no comments).<br>
> The x11spice project is another example: we have only 4 contributors<br>
> from the beginning of the year (and a single contributor holding 70% of<br>
> the commits) and the reviews on the gitlab merge requests have been<br>
> provided by two people only, each one reviewing the merge requests of<br>
> the other.<br>
> For the sake of having the projects being able to move forward with a<br>
> reduced number of contributors/reviewers, the proposal is to *allow* a<br>
> maintainer to merge a Merge Request without an explicit ack if the three<br>
> following conditions are met:<br>
> 1) The Merge Request has been pending for at least 3 weeks without<br>
> getting new comments<br>
> 2) The Merge Request submitter has kept asking a review on a weekly basis<br>
> 3) There are no pending nacks on the Merge Request<br>
> <br>
> Note that having patches reviewed would still be the preferred way. If<br>
> at any time the number of contributors would raise again, we can switch<br>
> back to the mandatory review rule. Until then the priority is to allow<br>
> the project to move forward.<br>
> <br>
> What do you think? Please share your thoughts and/or contribute with<br>
> your own ideas.<br>
> <br>
> Thanks<br>
> <br>
> Francesco<br>
> <br>
<br>
Hi,<br>
   I agree on the proposal. This problem has been going on for years now.<br>
The issue involve all repositories. The active part of community dealing<br>
with code review is very low.<br></blockquote><div><br></div><div>All open-source projects are under-staffed. Spice has had a number of paid developpers, and a number of paid developpers who can help when it is needed. This is better than a lot of projects.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I think 3 weeks are perfectly fine. We should be in a trustful community,<br></blockquote></div><div><br></div><div>I expressed my <span><span>anxiousness about that short period. This is not going to be healthy to put such constrain. If we were unhappy about the time it took to review a MR, we would need first to prioritize our work better, and reaching out for help. Not rush the changes, please.<br></span></span></div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
if somebody is very busy in daily activity or on holidays whomever remains<br>
should be in charge. Is not that is a person in a team goes on holiday all<br>
the work of the team is impeded.<br></blockquote><div><br></div><div>I don't think such "blocking" factor exist, because the Spice code base is large, and the domain as well. But in such exceptional circonstances, we can easily either find a consensus for an exception, or help each other to unblock the situation.<br></div></div><div><br></div><div>thanks<br></div><br>-- <br><div dir="ltr" class="gmail_signature">Marc-André Lureau<br></div></div>