On Fri, Jun 17, 2011 at 10:56 PM, Adam Barth aba...@webkit.org 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
On Fri, Jun 17, 2011 at 11:13 PM, Peter Kasting pkast...@chromium.org wrote:
On Fri, Jun 17, 2011 at 10:56 PM, Adam Barth aba...@webkit.org 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
The batterystatus can be unimportant for pages or apps.
Or, detail info is needed more than this.
But, before the spec is changed, I think there is no problem to support
this.
It is better to support to do not.
Can you be sure that this will be not used?
I think It is good to support to someone
There seems to be some confusion about what to do when you discover that a code
change caused a bug.
Please do *not* reopen the original bug report to say that the code change
caused a problem. This makes the bug database state that the original bug is
not fixed, and also makes the patch to
I noticed these three roll-outs:
http://trac.webkit.org/changeset/89190
http://trac.webkit.org/changeset/89191
http://trac.webkit.org/changeset/89192
Were all of these necessary? Was there a way to fix the problem instead of
rolling out in any of these cases?
-- Darin
On Jun 18, 2011, at 12:24 PM, Darin Adler wrote:
I noticed these three roll-outs:
http://trac.webkit.org/changeset/89190
http://trac.webkit.org/changeset/89191
In the case of these first two patches was any attempt made to actually fix the
qt build? Every other build was apparently
On Jun 17, 2011, at 10:56 PM, Adam Barth wrote:
There are a 194 open bugs with an R+ patches attached to them:
I worked on this and some others must have been working on it as well. The
number is down to 105 now, with quite a few in the commit queue. I ran out of
steam. I hope more others can
I'm running clean-pending-commit and clean-review-queue now. Adam and
I will make sure to set up a bot to run both next week.
-eric
On Sat, Jun 18, 2011 at 1:03 PM, Darin Adler da...@apple.com wrote:
On Jun 17, 2011, at 10:56 PM, Adam Barth wrote:
There are a 194 open bugs with an R+ patches
On Sat, Jun 18, 2011 at 1:15 PM, Darin Adler da...@apple.com wrote:
On Jun 18, 2011, at 12:58 PM, Oliver Hunt wrote:
On Jun 18, 2011, at 12:24 PM, Darin Adler wrote:
http://trac.webkit.org/changeset/89190
Looks like Ossy did look at this one; it was not a Qt issue at all, broken on
all
I should note that webkit-patch has some (hidden, see webkit-patch
help -a) commands for dealing with the review and commit queue
overflow:
clean-pending-commit -- obsoletes patches with r+ on closed bugs,
clears r+ on obsolete patches
clean-review-queue -- obsoletes r? patches on closed bugs
1:
Recently, Alexey has encouraged me to use PassRefPtr less for function
arguments.
The PassRefPtr optimization pays off when the object in question is possibly
being handed off from one PassRefPtr to another. For an argument, that can
happen in two ways: 1) The argument can be the result of
I've fixed many a security bug cause by not refing local variables.
Generally, you need to ref your local variables if any function you call can
end up executing JavaScript (and many can). If you're not sure, please feel
encouraged to ask around.
Adam
On Jun 18, 2011 8:54 PM, Darin Adler
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
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
On Jun 18, 2011, at 5:52 PM, Darin Adler wrote:
1:
Recently, Alexey has encouraged me to use PassRefPtr less for function
arguments.
The PassRefPtr optimization pays off when the object in question is possibly
being handed off from one PassRefPtr to another. For an argument, that can
18.06.2011, в 22:15, Maciej Stachowiak написал(а):
- I think having a rule for using PassRefPtr for arguments that depends on
how callers use the function is likely to be hard to use in practice, since
it requires global knowledge of all callers to pick the right function
signature. The
16 matches
Mail list logo
