[webkit-dev] 194 bugs in pending-commit
There are a 194 open bugs with an R+ patches attached to them: https://bugs.webkit.org/buglist.cgi?query_format=advanced&short_desc_type=notregexp&short_desc=%5C%5BS60%5C%5D&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=review%2B&field0-1-0=noop&type0-1-0=equals&value0-1-0= Please take a minute to look through this list and clean out any bugs you know about. (Looks like 5 of them are assigned to me, so I'll be following my own advice shortly.) Some recommended actions: 1) Close the bug if the patch has already been landed. 2) Mark the patch as obsolete / clear the review flag if we're not going to land the patch. 3) Mark the patch commit-queue+ if you'd like the commit queue to land the patch. 4) Land the patch manually if the patch needs some tweaking before landing. Thanks, and happy bug scrubbing! Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] 194 bugs in pending-commit
On Fri, Jun 17, 2011 at 10:56 PM, Adam Barth wrote: > 2) Mark the patch as obsolete / clear the review flag if we're not > going to land the patch. Does the slash mean "do both"? I have https://bugs.webkit.org/show_bug.cgi?id=47036 on that list and the only r+ed patch on it is already marked obsolete. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] 194 bugs in pending-commit
On Fri, Jun 17, 2011 at 11:13 PM, Peter Kasting wrote: > On Fri, Jun 17, 2011 at 10:56 PM, Adam Barth wrote: >> 2) Mark the patch as obsolete / clear the review flag if we're not >> going to land the patch. > > Does the slash mean "do both"? I > have https://bugs.webkit.org/show_bug.cgi?id=47036 on that list and the only > r+ed patch on it is already marked obsolete. Yeah, Bugzilla kind of sucks. That page isn't smart enough to hide the obsolete patches. If you have EditBugs, you can run "webkit-patch clean-pending-commit", which will automatically remove the review flags from obsolete patches. Eric and I have been meaning to having one of the bots do that periodically, but we haven't set that up yet. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] 194 bugs in pending-commit
IIRC, Mozilla's bugzilla can "hide" obsolete patches (?). If so, why can not webkit's bugzilla? I actually do not like the way the review flags are cleared today only in order to make the tools and pending-xxx pages happier. IMO the review flags give much about the history of the bug. In that matter, I dislike webkit-patch's ways of clearing "r-" flags of patches while it marks it as obsolete and uploads a new one. Reason: an easy-to-see r-'ed patch is very helpful to me to understand the chronological progresses in the bug. What is the reason for clearing r- flag while uploading a new one, instead of only making it obsolete? On Sat, Jun 18, 2011 at 2:23 AM, Adam Barth wrote: > On Fri, Jun 17, 2011 at 11:13 PM, Peter Kasting > wrote: > > On Fri, Jun 17, 2011 at 10:56 PM, Adam Barth wrote: > >> 2) Mark the patch as obsolete / clear the review flag if we're not > >> going to land the patch. > > > > Does the slash mean "do both"? I > > have https://bugs.webkit.org/show_bug.cgi?id=47036 on that list and the > only > > r+ed patch on it is already marked obsolete. > > Yeah, Bugzilla kind of sucks. That page isn't smart enough to hide > the obsolete patches. If you have EditBugs, you can run "webkit-patch > clean-pending-commit", which will automatically remove the review > flags from obsolete patches. Eric and I have been meaning to having > one of the bots do that periodically, but we haven't set that up yet. > > Adam > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] 194 bugs in pending-commit
webkit-patch upload clears all flags when obsoleting a patch. We could make it not clear r- if you like. I know of no way to construct a query like http://webkit.org/pending-commit in our current bugzilla without clearing r+ on obsolete patches/closed bugs. We clear flags (specifically r+) to make the life of those going through http://webkit.org/pending-commit easier (like sever folks tried to do this afternoon). Similarly, our current bugzilla doesn't automatically clear r? on closed bugs. So we have webkit-patch clean-review-queue to do that. The history information for any bug is always easily accessed via the "history" link in the upper-right corner of a bug, like: https://bugs.webkit.org/show_activity.cgi?id=62114 -eric On Sat, Jun 18, 2011 at 9:01 PM, Antonio Gomes wrote: > IIRC, Mozilla's bugzilla can "hide" obsolete patches (?). If so, why can not > webkit's bugzilla? > > I actually do not like the way the review flags are cleared today only in > order to make the tools and pending-xxx pages happier. IMO the review flags > give much about the history of the bug. In that matter, I dislike > webkit-patch's ways of clearing "r-" flags of patches while it marks it as > obsolete and uploads a new one. Reason: an easy-to-see r-'ed patch is very > helpful to me to understand the chronological progresses in the bug. > > What is the reason for clearing r- flag while uploading a new one, instead > of only making it obsolete? > > On Sat, Jun 18, 2011 at 2:23 AM, Adam Barth wrote: >> >> On Fri, Jun 17, 2011 at 11:13 PM, Peter Kasting >> wrote: >> > On Fri, Jun 17, 2011 at 10:56 PM, Adam Barth wrote: >> >> 2) Mark the patch as obsolete / clear the review flag if we're not >> >> going to land the patch. >> > >> > Does the slash mean "do both"? I >> > have https://bugs.webkit.org/show_bug.cgi?id=47036 on that list and the >> > only >> > r+ed patch on it is already marked obsolete. >> >> Yeah, Bugzilla kind of sucks. That page isn't smart enough to hide >> the obsolete patches. If you have EditBugs, you can run "webkit-patch >> clean-pending-commit", which will automatically remove the review >> flags from obsolete patches. Eric and I have been meaning to having >> one of the bots do that periodically, but we haven't set that up yet. >> >> Adam >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > > -- > --Antonio Gomes > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] 194 bugs in pending-commit
On a similar note of bug cleanup, I have also seen lot of issues which are still in Unconfirmed state, even though the bug analysis says either the issue is not reproducible etc etc. So, Is there a way to clean up such bugs so that they don't unnecessarily come up in queries. What is the traditional procedure we follow in such cases? Thanks, Rahaman On Sun, Jun 19, 2011 at 10:18 AM, Eric Seidel wrote: > webkit-patch upload clears all flags when obsoleting a patch. We > could make it not clear r- if you like. I know of no way to construct > a query like http://webkit.org/pending-commit in our current bugzilla > without clearing r+ on obsolete patches/closed bugs. We clear flags > (specifically r+) to make the life of those going through > http://webkit.org/pending-commit easier (like sever folks tried to do > this afternoon). > > Similarly, our current bugzilla doesn't automatically clear r? on > closed bugs. So we have webkit-patch clean-review-queue to do that. > > The history information for any bug is always easily accessed via the > "history" link in the upper-right corner of a bug, like: > https://bugs.webkit.org/show_activity.cgi?id=62114 > > -eric > > > On Sat, Jun 18, 2011 at 9:01 PM, Antonio Gomes > wrote: > > IIRC, Mozilla's bugzilla can "hide" obsolete patches (?). If so, why can > not > > webkit's bugzilla? > > > > I actually do not like the way the review flags are cleared today only in > > order to make the tools and pending-xxx pages happier. IMO the review > flags > > give much about the history of the bug. In that matter, I dislike > > webkit-patch's ways of clearing "r-" flags of patches while it marks it > as > > obsolete and uploads a new one. Reason: an easy-to-see r-'ed patch is > very > > helpful to me to understand the chronological progresses in the bug. > > > > What is the reason for clearing r- flag while uploading a new one, > instead > > of only making it obsolete? > > > > On Sat, Jun 18, 2011 at 2:23 AM, Adam Barth wrote: > >> > >> On Fri, Jun 17, 2011 at 11:13 PM, Peter Kasting > >> wrote: > >> > On Fri, Jun 17, 2011 at 10:56 PM, Adam Barth > wrote: > >> >> 2) Mark the patch as obsolete / clear the review flag if we're not > >> >> going to land the patch. > >> > > >> > Does the slash mean "do both"? I > >> > have https://bugs.webkit.org/show_bug.cgi?id=47036 on that list and > the > >> > only > >> > r+ed patch on it is already marked obsolete. > >> > >> Yeah, Bugzilla kind of sucks. That page isn't smart enough to hide > >> the obsolete patches. If you have EditBugs, you can run "webkit-patch > >> clean-pending-commit", which will automatically remove the review > >> flags from obsolete patches. Eric and I have been meaning to having > >> one of the bots do that periodically, but we haven't set that up yet. > >> > >> Adam > >> ___ > >> webkit-dev mailing list > >> webkit-dev@lists.webkit.org > >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > > > > > > -- > > --Antonio Gomes > > > > ___ > > webkit-dev mailing list > > webkit-dev@lists.webkit.org > > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] 194 bugs in pending-commit
I had one of the bugs in this state, and I had not landed it because I had been meaning to do some more testing to see if it caused regressions. However, someone CQ+'ed it over the weekend, and it was committed w/o my involvement. Fortunately, it did not appear to cause massive regressions (thankfully, since I wasn't around and wouldn't have been able to triage/diagnose any issues), but, for at least some patches, I would like to prevent this from occurring in the future. Would it have been better to mark the patch as CQ- just to be safer (and clearer), or is there some other recommended way to indicate that I want a patch to be reviewed but it may not be ready to be landed? -- Dirk On Fri, Jun 17, 2011 at 10:56 PM, Adam Barth wrote: > There are a 194 open bugs with an R+ patches attached to them: > > https://bugs.webkit.org/buglist.cgi?query_format=advanced&short_desc_type=notregexp&short_desc=%5C%5BS60%5C%5D&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=review%2B&field0-1-0=noop&type0-1-0=equals&value0-1-0= > > Please take a minute to look through this list and clean out any bugs > you know about. (Looks like 5 of them are assigned to me, so I'll be > following my own advice shortly.) Some recommended actions: > > 1) Close the bug if the patch has already been landed. > 2) Mark the patch as obsolete / clear the review flag if we're not > going to land the patch. > 3) Mark the patch commit-queue+ if you'd like the commit queue to land > the patch. > 4) Land the patch manually if the patch needs some tweaking before landing. > > Thanks, and happy bug scrubbing! > Adam > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] 194 bugs in pending-commit
If you want to be extra sure that someone won't commit-queue your patch, you can mark it commit-queue-. Generally, though, we don't mark patches from committers commit-queue+ unless the committer has marked the patch commit-queue?. Adam On Mon, Jun 20, 2011 at 11:35 AM, Dirk Pranke wrote: > I had one of the bugs in this state, and I had not landed it because I > had been meaning to do some more testing to see if it caused > regressions. However, someone CQ+'ed it over the weekend, and it was > committed w/o my involvement. Fortunately, it did not appear to cause > massive regressions (thankfully, since I wasn't around and wouldn't > have been able to triage/diagnose any issues), but, for at least some > patches, I would like to prevent this from occurring in the future. > > Would it have been better to mark the patch as CQ- just to be safer > (and clearer), or is there some other recommended way to indicate that > I want a patch to be reviewed but it may not be ready to be landed? > > -- Dirk > > On Fri, Jun 17, 2011 at 10:56 PM, Adam Barth wrote: >> There are a 194 open bugs with an R+ patches attached to them: >> >> https://bugs.webkit.org/buglist.cgi?query_format=advanced&short_desc_type=notregexp&short_desc=%5C%5BS60%5C%5D&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=review%2B&field0-1-0=noop&type0-1-0=equals&value0-1-0= >> >> Please take a minute to look through this list and clean out any bugs >> you know about. (Looks like 5 of them are assigned to me, so I'll be >> following my own advice shortly.) Some recommended actions: >> >> 1) Close the bug if the patch has already been landed. >> 2) Mark the patch as obsolete / clear the review flag if we're not >> going to land the patch. >> 3) Mark the patch commit-queue+ if you'd like the commit queue to land >> the patch. >> 4) Land the patch manually if the patch needs some tweaking before landing. >> >> Thanks, and happy bug scrubbing! >> Adam >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] 194 bugs in pending-commit
In general it's pretty safe to cq+ a patch, especially an old one. Since the cq + EWS tests patches better than just about any committer ever does manually. :) We built infrastructure to have the sherriff-bot auto-rollout patches which caused any tree redness. If folks want, we could turn that on, which gets rid of the "the cq might land my patch while I'm not looking" problem. But yes, setting cq- is a great way to make sure no one cq+'s your patch. -eric On Mon, Jun 20, 2011 at 11:50 AM, Adam Barth wrote: > If you want to be extra sure that someone won't commit-queue your > patch, you can mark it commit-queue-. Generally, though, we don't > mark patches from committers commit-queue+ unless the committer has > marked the patch commit-queue?. > > Adam > > > On Mon, Jun 20, 2011 at 11:35 AM, Dirk Pranke wrote: >> I had one of the bugs in this state, and I had not landed it because I >> had been meaning to do some more testing to see if it caused >> regressions. However, someone CQ+'ed it over the weekend, and it was >> committed w/o my involvement. Fortunately, it did not appear to cause >> massive regressions (thankfully, since I wasn't around and wouldn't >> have been able to triage/diagnose any issues), but, for at least some >> patches, I would like to prevent this from occurring in the future. >> >> Would it have been better to mark the patch as CQ- just to be safer >> (and clearer), or is there some other recommended way to indicate that >> I want a patch to be reviewed but it may not be ready to be landed? >> >> -- Dirk >> >> On Fri, Jun 17, 2011 at 10:56 PM, Adam Barth wrote: >>> There are a 194 open bugs with an R+ patches attached to them: >>> >>> https://bugs.webkit.org/buglist.cgi?query_format=advanced&short_desc_type=notregexp&short_desc=%5C%5BS60%5C%5D&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=review%2B&field0-1-0=noop&type0-1-0=equals&value0-1-0= >>> >>> Please take a minute to look through this list and clean out any bugs >>> you know about. (Looks like 5 of them are assigned to me, so I'll be >>> following my own advice shortly.) Some recommended actions: >>> >>> 1) Close the bug if the patch has already been landed. >>> 2) Mark the patch as obsolete / clear the review flag if we're not >>> going to land the patch. >>> 3) Mark the patch commit-queue+ if you'd like the commit queue to land >>> the patch. >>> 4) Land the patch manually if the patch needs some tweaking before landing. >>> >>> Thanks, and happy bug scrubbing! >>> Adam >>> ___ >>> webkit-dev mailing list >>> webkit-dev@lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >> > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
