[Mesa-dev] Patchwork review process (efficiency) questions
Rob Clark
robdclark at gmail.com
Fri Jun 3 12:10:11 UTC 2016
On Fri, Jun 3, 2016 at 7:12 AM, ⚛ <0xe2.0x9a.0x9b at gmail.com> wrote:
> Hello
>
> Situation: Looking at the content displayed by the web browser for URL
> http://patchwork.freedesktop.org/project/mesa/series and sub-pages
> accessible via the links.
>
> The following questions are troubling me:
>
> - How does a patch submitter know when a reviewer will take a look at the patch?
There is a scripts/get_reviewers.pl (based on linux kernel
get_maintainers.pl script) which can be used as git-cccmd and will add
appropriate people in CC when you send the patch. This helps to get
the right people to notice the patch.
But in general the responsibility is on the patch sender to follow
up.. there is limited review bandwidth to go around, and sometimes the
person(s) who could review some particular patch get busy. Sometimes
you need to ping people on IRC, etc, to remind them.
> - What is the order in which the reviewers are looking at the patches?
> - What is the influence of the default ordering (URL suffix
> "?ordering=-last_updated") on the behavior of reviewers?
> - What about those patches on the 10th page from previous year? Why
> are they in the list?
possibly defunct patches (maybe it was decided to follow a different
approach to solve a particular problem, etc).. or possibly just things
that were forgotten
> - Do patch submitters regularly clean up outdated patches?
there are commit hooks which change the state of patches that get
pushed. Other than that, it's probably been a while since anyone went
through. But IMO it would be ok just to kill patches that are too
old.
> - Does a patch submitter receive a notification email when he/she
> forgets about a patch over time?
No, like I said the responsibility is on the patch sender.
I usually keep patches in a local branch that I rebase periodically,
so I can see what hasn't been pushed yet.
> It seems to me that the current review process isn't as efficient as it can be.
The limit is really reviewer bandwidth. There is no silver bullet
here. We all still only have 24hrs in a day.
BR,
-R
> Looking forward to your opinions and solutions.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
More information about the mesa-dev
mailing list