lack of reviewers (Re: first set of new APIs + convert server to use them)

Peter Hutterer peter.hutterer at
Mon May 14 23:58:50 PDT 2012

On Mon, May 14, 2012 at 07:22:48PM +0100, Dave Airlie wrote:
> On Mon, May 14, 2012 at 7:04 PM, Alan Coopersmith
> <alan.coopersmith at> wrote:
> > On 05/14/12 04:28 AM, Dave Airlie wrote:
> >> nobody? ping?
> >>
> >> Like Keith the glyph picture API patch is like 2 lines long :)
> >>
> >> /me wonders how I'm going to get the next 50 patches in at this rate
> >> some time this year.
> >
> > It's not just you, we seem to be having a harder time getting reviews done
> > all around.
> >
> > (I admit I'm as guilty of this as the rest, since I've been busy on other
> >  things, and less motivated to review for other people when I can't get
> >  my patches reviewed.)
> >
> > I've got no ideas how to fix this quickly, but we need to get it fixed.
> >
> > Patchwork only helps if we get the finished reviews cleared off - right now
> > everything is listed as needing review, even if we've integrated it,
> > reworked it, or rejected it.
> I've pretty much no idea how to deal with it sanely. We've moved to larger
> scale development model without a larger set of developers. The kernel
> isn't even as stringent wrt to reviews as xorg-devel is.

then we fix the process? it's not like it's written in stone. IMO having at
least one more person in the loop to build before pushing is already
quite useful to catch issues like missing git adds or spurious API breaks.

one reason the current review process is in place is because before 1.8, the
server was rather unpredictable and even getting one that built was a bit of
luck. This has changed, and all patches at least show up on the list now.
I'm pretty sure I've gotten comments about potential bugs from reviewers
that otherwise wouldn't have added a rev-by.

Another thing is that feature-branch development didn't really exist
before 1.8. I think that has changed now as well.

so I think loosening the review requirements is not the worst of all ideas,
though it shouldn't be seen as a free-for-all.


> I'm guessing we'll probably have to have review swap parties or meetings
> or something insane like that to clear the backlog on occasions,
> it would be nice if patchwork could be kept up to date, but it would involve
> anyone handling patches to jump on and clean up the ones they've merged
> already.
> I spent a major amount of my time either reviewing kernel patches, or
> persuading others to review other peoples patches so I don't have to,
> I'm not sure if we need some more tracking from Keith or others on
> what unreviewed stuff is outstanding and who best to direct it to, but
> again it involves a time commitment from someone and I've no idea
> who could afford it.
> Like the input guys have a bit of crossover work, the build system
> stuff seems to be covered, but the rest of the server is a wasteland
> of unreviewedness.

More information about the xorg-devel mailing list