16.03.2012, 04:41, Adam Barth aba...@webkit.org:
Hi webkit-dev,
After reading last week's discussion about switching the project to
git, I wondered if it would be possible to get some of the benefits of
git-style development without forcing everyone to switch to git.
One of the benefits
On Fri, Mar 16, 2012 at 6:50 PM, Konstantin Tokarev annu...@yandex.ru wrote:
16.03.2012, 04:41, Adam Barth aba...@webkit.org:
Hi webkit-dev,
After reading last week's discussion about switching the project to
git, I wondered if it would be possible to get some of the benefits of
git-style
Hi. Webkit-dev.
I want to let you know that the Battery Status API is just landed.
: https://bugs.webkit.org/show_bug.cgi?id=62698,
http://www.w3.org/TR/battery-status/
This is behind ENABLE_BATTERY_STATUS feature define.
This feature is enabled on the Efl port now. If you have any comments or
Hello webkit-dev,
We would like to upstream our implementation of W3C Sensor API [1].
As we are aware that this is a young specification, we propose to have
it default #ifdef-disabled.
However, we believe it could be useful for certain ports or useful for
being accessed by Chrome extensions.
No, as far as I can tell the servers are operating normally. From home, I can
checkout webkit in 30 minutes, which is of course very close to the servers,
but not much closer than Mountain View. My home trace does not seem to go
through Level 3, so maybe its a 3rd party network issue. I've
The specification appears to be here:
http://dvcs.w3.org/hg/dap/raw-file/tip/sensor-api/Overview.html
Has this specification reached FPWD yet? http://www.w3.org/TR/sensor/
returns a 404.
Adam
2012/3/16 Dominik Röttsches dominik.rottsc...@linux.intel.com:
Hello webkit-dev,
We would like to
On Fri, Mar 16, 2012 at 8:23 AM, William Siegrist wsiegr...@apple.comwrote:
No, as far as I can tell the servers are operating normally. From home, I
can checkout webkit in 30 minutes, which is of course very close to the
servers, but not much closer than Mountain View. My home trace does not
On Mar 16, 2012, at 9:26 AM, Ryosuke Niwa rn...@webkit.org wrote:
As I stated on this thread, I was getting reasonable download speed from svn
and others at home (Comcast business in SF). You may want to compare my
traceroute to others and see if there's a difference.
I have been
Hi WebKit-dev,
WebSocket protocol specification became RFC, and all existing ports I'm
aware of (in public WebKit repository) have switched to using the RFC
version.
So, I'm planning to (1) flip the WebKit-global flag to use the RFC protocol
by default, (2) drop the support of the old hixie-76
On 16 March 2012 18:34, Ryosuke Niwa rn...@webkit.org wrote:
If some reviewer and committer decide to use this process, where can I see
review comments and other discussions?
See point 3 of Landing your code. Reviewer adds a link to pull
request in changelog.
Would they still be on
On Fri, Mar 16, 2012 at 12:20 PM, John Yani van...@gmail.com wrote:
On 16 March 2012 18:34, Ryosuke Niwa rn...@webkit.org wrote:
If some reviewer and committer decide to use this process, where can I see
review comments and other discussions?
See point 3 of Landing your code. Reviewer adds a
On Fri, Mar 16, 2012 at 12:41 PM, Ariya Hidayat ariya.hida...@gmail.com wrote:
See point 3 of Landing your code. Reviewer adds a link to pull
request in changelog.
But now it means I have to search in two places: Bugzilla and Github,
in case I want to look up some past issues/problems.
On Fri, Mar 16, 2012 at 3:41 PM, Ariya Hidayat ariya.hida...@gmail.comwrote:
See point 3 of Landing your code. Reviewer adds a link to pull
request in changelog.
But now it means I have to search in two places: Bugzilla and Github,
in case I want to look up some past issues/problems.
Bugs.webkit.org has an integrated bug tracking and code review tool. I find
this integration is good as it stands. I use git for development and don't
think there's anything wrong with the current tools.
Konrad
Sent from my BlackBerry on the Rogers Wireless Network
From: Jarred Nicholls
GitHub's API has hooks/events for comments on issues PRs to where it would
be possible to integrate WebKit's GitHub mirror with Bugzilla so that all
comments on PRs could post back to the related Bugzilla bug. Some
convention would be necessary in the PR title or description to figure out
Totally on board with this.
From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org]
on behalf of Ryosuke Niwa [rn...@webkit.org]
Sent: Friday, March 16, 2012 2:06 PM
To: Yuta Kitamura
Cc: WebKit Development
Subject: Re: [webkit-dev]
Historically, the WebKit project hasn't had the warmest relationship
with the DAP working group, and we've tended to be conservative about
which DAP APIs we merge into trunk. The Sensor API appears to be
fairly early in its lifecycle. As far as I can tell, it hasn't even
reached FPWD, which
On Mar 16, 2012 12:47 PM, Adam Barth aba...@webkit.org wrote:
On Fri, Mar 16, 2012 at 12:41 PM, Ariya Hidayat ariya.hida...@gmail.com
wrote:
See point 3 of Landing your code. Reviewer adds a link to pull
request in changelog.
But now it means I have to search in two places: Bugzilla
On Fri, Mar 16, 2012 at 2:32 PM, Ryosuke Niwa rn...@webkit.org wrote:
Can we do some Bugzilla integration as Jarred suggested?
If you're excited about using GitHub, you should feel free to do that work.
Note: I'm not advocating for the use of GitHub. I'm just documenting
a way that
Okay, thanks for the clarification. I'm not particularly interested in
using this approach myself. I just wanted to make sure that I can see
review comments for bugs I'm cc'ed on before patches are landed if some
contrinutors do decide to experiment with this approach.
- Ryosuke
On Mar 16, 2012
I think this feature is pretty far out relative to WebKit project goals, even
independent of spec maturity level.
We've had controversy (though ultimately tentative agreement on adding) APIs
for hardware found in some but not all classes of mainstream hardware that runs
a browser. For
21 matches
Mail list logo
