[webkit-dev] Patch process - let's make it better

Adam Treat treat at kde.org
Wed Jul 15 13:14:45 PDT 2009

On Friday 10 July 2009 06:55:59 pm Maciej Stachowiak wrote:
> * Phase 1 *
> A) Make it really easy to submit a patch. Eric's bugzilla-tool is
> close to being there. I'm going to help him refine this tool to the
> point that submitting a patch has only one step - a single command
> will make the patch, file a bug if needed, attach the patch to the
> bug, and flag it for review.
> B) Make it really easy to commit a patch. Again, I think bugzilla-tool
> is the right path to achieving this.
> C) Improve the way we get attention from reviewers. I think we should
> do three things here:
>      C.1) Split review queues, based on our emerging [Bracket]
> convention for patches needing specialized review. If we find more
> areas of specialty besides ports, we can add new [Bracket] tags.
>      C.2) Improve the quality of emails sent
>      C.3) Highlight in a special way patches that have been waiting
> for review longer that some minimum period (a week?). These could be
> highlighted visually in the review queue, and maybe would send extra
> review request emails automatically.

Speaking of your action plan... I've had a look at C.3 and was going to try to 
modify the bugzilla tools to highlight as you suggested.  But after looking at 
the review queue over the last few days I'm not sure it is necessary or that 
it would help to fix the problem.


The page above already lists the review queue sorted by date.  Over the last 
few days the queue has numbered in the 100's.  A significant fraction (50%+) 
are older than a week.  I could highlight them, but if it is already ordered 
by date and the highlight will encompass more than half the queue... what's 
the point?



More information about the webkit-dev mailing list