[webkit-dev] 194 bugs in pending-commit

[Eric Seidel]

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 <abarth at webkit.org> 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 <dpranke at chromium.org> 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 <abarth at webkit.org> 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 at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>