It would be helpful, in terms of evaluating review request responsiveness, to have a way to look at a list of all bugs in a particular period of time in which a review has been requested of me, then either granted by someone else, transferred to someone else by the patch’s author, or removed due to a newer attachment being posted with review directed at someone else. The basic idea is to figure out how to measure whether other people are switching to other reviewers due to review latency, when requesters are sufficiently knowledgeable/motivated to switch rather than have an old review sit in a request queue forever. There’s no precise way to measure exactly this statistic. Someone else granting a review request might just be that that person was marginally more responsive on IRC to a quick request made after the initial flagging in Bugzilla. A review transfer may have been done with consent of both parties for reasons unrelated to review delay. A newer attachment with different reviewer might be an acknowledgment of a patch’s changing scope (whose most competent reviewer therefore changed). The point isn’t to get an exact idea, just to give the list of bugs so that one could examine the list, manually filter out false positives, and get some sort of rough idea of how good or bad review responsiveness has been.
A sufficiently granular bugmail search could probably tell me this, but I suspect extracting that information from lightly-structured text is much harder than working on Bugzilla or its data directly, and I’m not sure if my email account could easily accommodate such a search (and that solution’s not generally applicable).
So, lazyweb…make my life easier for me. 🙂
…to Delta for, it seems, making an intentional effort to design their website such that it works if you don’t have a working version of Flash. (I have Flash installed, but obnoxious advertising and CPU churn have induced me to enable it only in an opt-in manner — also handy for avoiding rickrolls!) When I view their site after logging in, I notice I’m viewing this address:
If comparefn is not
undefinedand is not a consistent comparison function for the elements of this array (see below), the behaviour of
A function comparefn is a consistent comparison function for a set of values S if all of the requirements below are met for all values a, b, and c (possibly the same value) in the set S: The notation a <CF b means comparefn(a,b) < 0; a =CF b means comparefn(a,b) = 0 (of either sign); and a >CF b means comparefn(a,b) > 0.
- Calling comparefn(a,b) always returns the same value v when given a specific pair of values a and b as its two arguments. Furthermore, Type(v) is Number, and v is not
NaN. Note that this implies that exactly one of a <CF b, a =CF b, and a >CF b will be true for a given pair of a and b.
- Calling comparefn(a,b) does not modify the
- a =CF a (reflexivity)
- If a =CF b, then b =CF a (symmetry)
- If a =CF b and b =CF c, then a =CF c (transitivity of =CF)
- If a <CF b and b <CF c, then a <CF c (transitivity of <CF)
- If a >CF b and b >CF c, then a >CF c (transitivity of >CF)
#define WORKAROUND(cx_, saver_) \ Workaround WORKAROUND_PASTE(w_, __LINE__)((cx_), (saver_)) #define WORKAROUND_PASTE(a_, b_) WORKAROUND_PASTE2(a_, b_) #define WORKAROUND_PASTE2(a_, b_) a_ ## b_ /* having fun yet? */ #define SAVER(cx_, saver_) \ AutoValueRooter saver_(cx_); \ WORKAROUND((cx_), (saver_));