I'll try to get bugs filed for any part of the plan that isn't done by
tomorrow, and I'll tag them with a keyword so we can track progress.
On Jul 15, 2009, at 1:14 PM, Adam Treat wrote:
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.
http://www.webkit.org/pending-review
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?
I tend to use this URL to scan the review queue instead:
https://bugs.webkit.org/buglist.cgi?field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=review%3F
I have few problems with the official review queue page, and maybe
what we need to do is come up with one version that has the benefits
of both. Here are the things I don't like about the pending-review page:
1) Uses two lines per bug plus a table border, so you can see fewer
items at once. I can see 13 in a max-height browser window on my
MacBook Pro, compared to 25 using my preferred query.
2) It splits out bugs with a specific requestee into separate lists,
this is I think harmful to prompt review because usually those bugs
don't really need review from one specific person.
3) Lists multiple patches on a single bug separately. I don't like
this, usually such patches should be reviewed together, and it
inflates the list.
4) No summary count.
Here are things I like about it, compared to a vanilla query:
1) Skips most of the irrelevant fields, like priority, assignee,
status, etc.
2) Sorts by date of request.
I would love to have a single view that combines the best of both ways
of viewing the review queue.
That being said, I think highlighting old bugs is good to do right
now. Even though today, 50% are older than a week, we don't want that
to be the norm. By marking them in a clear way (and maybe further
highlighting patches older than a month), we can help get to a point
where this is the exception, not the norm.
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
