<div dir="ltr"><div>Hi<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 15, 2020 at 7:06 PM Francesco Giudici <<a href="mailto:fgiudici@redhat.com">fgiudici@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">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></blockquote><div><br></div><div>I wasn't aware of a maintenance problem. Perhaps we should first list the projects that have maintenance issues & discuss our options, before changing the common rule.</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">
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></blockquote><div><br></div><div>You are omitting the passive reviewers. I consider myself as one of them. If you need people to be more proactive, you could at least reach me & probably others past contributors.</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">
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></blockquote><div><br></div><div>As projects become more specific/marginal, it's clear that the number of maintainers is lower. Yet, we have those projects under the same umbrella, and I don't think they should be treated differently. 2 active developers/maintainers can be very healthy, I would say. So do we have a maintenance issue with x11spice? Do we want to move the project out of the "Spice-space" projects for ex? What is the problem exactly?<br></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">
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></blockquote><div><br></div><div>It's hard to define a delay to bypass a reviewing & consensus rule. In general, it should really be frowned upon. There is clearly more than one person interested and using Spice. If the issue is important, it should be fairly easy to get someone else to look at the issue in a timely manner. If not, there are probably more important/interesting things to do to get other interested.</div><div><br></div><div>If Spice is good enough for our users and interested parties, then it may be risky to change it in wild directions without their approval.<br><br>But 3 weeks is way too short. You could have more important work, family issue, get sick and go on holiday, all happening each after the other. If we need you to review some code, because you have the best experience, we should wait. If really we want a delay, I would argue waiting 3 months minimum (there might be exceptional circumstances, but they are exception, not the rule). And during that time, the contributor should have attempted multiple time to involve people, by different means (at least ML, irc and gitlab issue+MR - eventually try a conf call to explain the motivation, present the work differently etc, complain about the Spice project laziness on public blog if need be etc).<br><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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></blockquote><div><br></div><div>Thanks, but I think the trivial rule is already very subtle and generally disapproved (fwiw, I am still in favor of a subjective trivial rule), so I don't think this proposal would work.</div><div><br></div><div>We have to grow a community, by convincing people and doing interesting work. Not by doing personal thing, and then leave the pieces behind, because we did it alone and didn't gather others.</div><div><br></div><div>Perhaps Spice is doing the job. Perhaps Spice needs to define new objectives. These are interesting topics that I believe people would want to discuss and participate. If not, we are doing it wrong.<br></div><div><br></div><div>thanks</div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature">Marc-André Lureau<br></div></div>