Re: [webkit-dev] (no subject)
En 28/02/12 04:46, Ryosuke Niwa escribiu: Do people really use git diff that often? I don't use git much but when I do I always get annoyed by the way git diff works because I almost always want git diff master. From my own experience, when you're used to a git workflow, you almost never mean git diff master when you do git diff. BR ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] (no subject)
En 28/02/12 22:06, Dirk Pranke escribiu: I'm beginning to think it probably makes sense to add a different commandline argument that works exactly like diff (e.g. takes an optional second value). --git-diff perhaps? Based on the responses on this thread, I agree with you. It looks like a fair number of people either want cherry-pick or diff against remote master. I will probably implement a separate switch for pure git. Although I normally use it for cherry-picking a commit to upload, I have always missed the option to upload a bunch of commits as a single patch. Basically, as you said, forcing people to merge several commits in a single one to upload a patch to bz totally breaks the typical git workflow (micro-commits and so). BR ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] (no subject)
29.02.2012, 12:26, Sergio Villar Senin svil...@igalia.com: En 28/02/12 22:06, Dirk Pranke escribiu: I'm beginning to think it probably makes sense to add a different commandline argument that works exactly like diff (e.g. takes an optional second value). --git-diff perhaps? Based on the responses on this thread, I agree with you. It looks like a fair number of people either want cherry-pick or diff against remote master. I will probably implement a separate switch for pure git. Although I normally use it for cherry-picking a commit to upload, I have always missed the option to upload a bunch of commits as a single patch. Basically, as you said, forcing people to merge several commits in a single one to upload a patch to bz totally breaks the typical git workflow (micro-commits and so). Do you know how to use git rebase -i? -- Regards, Konstantin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] (no subject)
En 29/02/12 09:33, Konstantin Tokarev escribiu: Although I normally use it for cherry-picking a commit to upload, I have always missed the option to upload a bunch of commits as a single patch. Basically, as you said, forcing people to merge several commits in a single one to upload a patch to bz totally breaks the typical git workflow (micro-commits and so). Do you know how to use git rebase -i? Konstantin, that's why I meant with merge several commits in a single one. You do not normally want to do that while you're developing a patch as having multiple commits gives you a lot of flexibility while developing. I normally have to create a new branch to rebase the commits I want in a single patch to upload it to the bz. That is annoying, that's why I said that having something like webkit-patch upload range_of_commits will be nice to have, as you wouldn't have to create a new branch and rebase several commits, just to upload a new patch to the bz. BR ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] git.webkit.org problem
Hi, git.webkit.org is behind svn.webkit.org again. :( r109205 is the latest svn commit, but r109202 in git. Unfortunately I can't commit to svn because this problem. Is it any trick to update my git-svn repo from svn? I set up my git svn repo about $http://trac.webkit.org/wiki/UsingGitWithWebKit : - git clone git://git.webkit.org/WebKit.git WebKit - git svn init --prefix=origin/ -T trunk http://svn.webkit.org/repository/webkit - git config --replace svn-remote.svn.fetch trunk:refs/remotes/origin/master br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] trac.webkit.org is down
Hi, As of ~20mins ago trac.webkit.org is down, webkit.org, bugs and build are OK. Don't know who to notify so I'm spamming webkit-dev, sorry. Who should be contacted in such cases? -Ash___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] SVN repository is down
Hi, http://svn.webkit.org is down. Could you please bring this up? Thanks, Ali ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] git.webkit.org problem
Is it any trick to update my git-svn repo from svn? I set up my git svn repo about $http://trac.webkit.org/wiki/UsingGitWithWebKit : - git clone git://git.webkit.org/WebKit.git WebKit - git svn init --prefix=origin/ -T trunk http://svn.webkit.org/repository/webkit - git config --replace svn-remote.svn.fetch trunk:refs/remotes/origin/master Usually, the only missing step here is 'git svn fetch'. However, when I run that now I get: RA layer request failed: OPTIONS of 'http://svn.webkit.org/repository/webkit': could not connect to server (http://svn.webkit.org) at /Users/davidbarr/libexec/git-core/git-svn line 2139 -- David Barr. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] trac.webkit.org is down
Update: trac.webkit.org was back up for a short while then died again. (Could
we the eastern-hemispherics be overloading it?)
Where previously it was not responding at all, now it's protesting...
Traceback (most recent call last): File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/api.py,
line 376, in send_error 'text/html') File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/chrome.py,
line 733, in render_template message = req.session.pop('chrome.%s.%d' %
(type_, i)) File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/api.py,
line 195, in __getattr__ value = self.callbacks[name](self) File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/main.py,
line 265, in _get_session return Session(self.env, req) File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/session.py,
line 157, in __init__ self.get_session(sid) File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/session.py,
line 178, in get_session super(Session, self).get_session(sid, authenticated)
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/session.py,
line 51, in get_session db = self.env.get_db_cnx() File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/env.py,
line 285, in get_db_cnx return DatabaseManager(self).get_connection() File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/db/api.py,
line 92, in get_connection return self._cnx_pool.get_cnx(self.timeout or None)
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/db/pool.py,
line 176, in get_cnx return _backend.get_cnx(self._connector, self._kwargs,
timeout) File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/db/pool.py,
line 109, in get_cnx cnx = connector.get_connection(**kwargs) File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/db/postgres_backend.py,
line 69, in get_connection params) File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/db/postgres_backend.py,
line 185, in __init__ cnx = psycopg.connect(' '.join(dsn))
OperationalError: server closed the connection unexpectedly This probably means
the server terminated abnormally before or while processing the request.
From: Ashod Nakashian ashodnakash...@yahoo.com
To: WebKit Development webkit-dev@lists.webkit.org
Sent: Wednesday, February 29, 2012 2:40 PM
Subject: [webkit-dev] trac.webkit.org is down
Hi,
As of ~20mins ago trac.webkit.org is down, webkit.org, bugs and build are OK.
Don't know who to notify so I'm spamming webkit-dev, sorry.
Who should be contacted in such cases?
-Ash
___
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] git.webkit.org problem
This should be fixed now. -Bill On Feb 29, 2012, at 3:19 AM, David Barr wrote: Is it any trick to update my git-svn repo from svn? I set up my git svn repo about $http://trac.webkit.org/wiki/UsingGitWithWebKit : - git clone git://git.webkit.org/WebKit.git WebKit - git svn init --prefix=origin/ -T trunk http://svn.webkit.org/repository/webkit - git config --replace svn-remote.svn.fetch trunk:refs/remotes/origin/master Usually, the only missing step here is 'git svn fetch'. However, when I run that now I get: RA layer request failed: OPTIONS of 'http://svn.webkit.org/repository/webkit': could not connect to server (http://svn.webkit.org) at /Users/davidbarr/libexec/git-core/git-svn line 2139 -- David Barr. ___ 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] git.webkit.org problem
Hi Bill, Would it be possible to get some more information on your/Lucas' plans on improving stability of the infrastructure? This was the third significant interruption within a week, and especially for us non-PST folks it's becoming quite inconvenient. Thanks, Peter On Wed, Feb 29, 2012 at 15:00, William Siegrist wsiegr...@apple.com wrote: This should be fixed now. -Bill On Feb 29, 2012, at 3:19 AM, David Barr wrote: Is it any trick to update my git-svn repo from svn? I set up my git svn repo about $http://trac.webkit.org/wiki/UsingGitWithWebKit : - git clone git://git.webkit.org/WebKit.git WebKit - git svn init --prefix=origin/ -T trunk http://svn.webkit.org/repository/webkit - git config --replace svn-remote.svn.fetch trunk:refs/remotes/origin/master Usually, the only missing step here is 'git svn fetch'. However, when I run that now I get: RA layer request failed: OPTIONS of 'http://svn.webkit.org/repository/webkit': could not connect to server (http://svn.webkit.org) at /Users/davidbarr/libexec/git-core/git-svn line 2139 -- David Barr. ___ 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] build.webkit.org is very sick
FYI, The build server seems to be acting up again. All build servers are either stuck starting or stopping queues with a long backlog building up. http://build.webkit.org/one_line_per_build is taking forever (upwards of a dozen seconds) to load. -Ash From: William Siegrist wsiegr...@apple.com To: Osztrogonac Csaba o...@inf.u-szeged.hu Cc: webkit-dev@lists.webkit.org Sent: Friday, February 24, 2012 6:55 PM Subject: Re: [webkit-dev] build.webkit.org is very sick I restarted the master so it's back for now. -Bill On Feb 23, 2012, at 11:05 PM, Osztrogonac Csaba wrote: Hi again, Now the things are going from bad to worse: Service Temporarily Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. :(( Are you planning to fix http://build.webkit.org in the near future? br, Ossy Osztrogonac Csaba írta: it seems build.webkit.org is very very sick. Almost all builds are broken with a strange exception and there are zillion strange stucked builds: building 1 min 1 min 1 min 1 min 1 min 1 min 1 min Could you check what happened? ___ 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] -webkit-transform-origin-x,y CSS properties
Are the -webkit-transform-origin-x,y CSS properties on their way in our
out? The ugly little test below demonstrates that they're probably not
supported by Opera or Mozilla.
CSSComputedStyleDeclaration::getPropertyCSSValue() in WebKit (explicitly)
ignores them. Should they stay or should they go? Or perhaps they
should just be left alone?
Thanks,
- Hans
html
style
div.square {
position: absolute;
top: 150px;
left: 150px;
width: 100px;
height: 100px;
background-color: blue;
-webkit-transform-origin-x: -150px;
-webkit-transform-origin-y: -150px;
-webkit-transition: -webkit-transform 0.5s;
-moz-transform-origin-x: -150px;
-moz-transform-origin-y: -150px;
-moz-transition: -moz-transform 0.5s;
-o-transform-origin-x: -150px;
-o-transform-origin-y: -150px;
-o-transition: -o-transform 0.5s;
}
div.square:hover {
-webkit-transform: rotate(45deg);
-webki-transition: -webkit-transform 0.5s;
-moz-transform: rotate(45deg);
-moz-transition: -moz-transform 0.5s;
-o-transform: rotate(45deg);
-o-transition: -o-transform 0.5s;
}
/style
body
div class=square/div
/body
/html
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] (no subject)
On Wed, Feb 29, 2012 at 12:43 AM, Sergio Villar Senin svil...@igalia.comwrote: En 29/02/12 09:33, Konstantin Tokarev escribiu: Although I normally use it for cherry-picking a commit to upload, I have always missed the option to upload a bunch of commits as a single patch. Basically, as you said, forcing people to merge several commits in a single one to upload a patch to bz totally breaks the typical git workflow (micro-commits and so). Do you know how to use git rebase -i? Konstantin, that's why I meant with merge several commits in a single one. You do not normally want to do that while you're developing a patch as having multiple commits gives you a lot of flexibility while developing. I normally have to create a new branch to rebase the commits I want in a single patch to upload it to the bz. That is annoying, that's why I said that having something like webkit-patch upload range_of_commits will be nice to have, as you wouldn't have to create a new branch and rebase several commits, just to upload a new patch to the bz. You can do this with the current -g option by adding a commit range, e.g. -g=commit1..commit2. AFAIK, the only thing you can't do currently with -g is pass a commit range *and* include the staged/working copy changes. Under the hood it basically does what you described (create a new branch, copy the commits over as a single commit, upload from the branch, etc). ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] (no subject)
En 29/02/12 18:42, Ojan Vafai escribiu: On Wed, Feb 29, 2012 at 12:43 AM, Sergio Villar Senin Do you know how to use git rebase -i? Konstantin, that's why I meant with merge several commits in a single one. You do not normally want to do that while you're developing a patch as having multiple commits gives you a lot of flexibility while developing. I normally have to create a new branch to rebase the commits I want in a single patch to upload it to the bz. That is annoying, that's why I said that having something like webkit-patch upload range_of_commits will be nice to have, as you wouldn't have to create a new branch and rebase several commits, just to upload a new patch to the bz. You can do this with the current -g option by adding a commit range, e.g. -g=commit1..commit2. AFAIK, the only thing you can't do currently with -g is pass a commit range *and* include the staged/working copy changes. Good to know. Thx Ojan for the clarification. BR ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Head-ups: massive TEXT rebaselining
Hi everyone,
TL;DR: If you don't maintain a bot or look at render tree dumps, I
guess this is not interesting to you.
I will land https://bugs.webkit.org/show_bug.cgi?id=75568 tomorrow to
give enough time for people to react. This makes us lazily allocate
layers when we get layout overflow. The upside is a good speed-up in
painting / hit-testing and (likely) some memory improvement but it
also means that 100+ tests will need a new baseline. I have tried to
skip those I know about in the different platforms but I may have
forgotten severals.
Here is the typical diff you should see:
---
/home/jchaffraix/Sources/WebKit/Source/WebKit/chromium/webkit/Debug/layout-test-results/fast/block/margin-collapse/103-expected.txt
+++
/home/jchaffraix/Sources/WebKit/Source/WebKit/chromium/webkit/Debug/layout-test-results/fast/block/margin-collapse/103-actual.txt
@@ -30,10 +30,12 @@
RenderText {#text} at (0,1) size 68x18
text run at (0,1) width 68: Your Name*
RenderTextControl {INPUT} at (325,27) size 184x22
[bgcolor=#FF] [border: (2px inset #00)]
+ RenderBlock {DIV} at (2,3) size 180x16
RenderBlock (floating) {SPAN} at (0,51) size 325x20 [color=#33]
RenderText {#text} at (0,1) size 121x18
text run at (0,1) width 121: Your e-mail address*
RenderTextControl {INPUT} at (325,51) size 184x22
[bgcolor=#FF] [border: (2px inset #00)]
+ RenderBlock {DIV} at (2,3) size 180x16
RenderBlock (floating) {SPAN} at (0,75) size 325x20 [color=#33]
RenderText {#text} at (0,1) size 128x18
text run at (0,1) width 128: Your degree program*
@@ -161,10 +163,6 @@
RenderBlock {SPAN} at (0,16) size 600x20 [color=#33]
RenderText {#text} at (245,1) size 110x18
text run at (245,1) width 110: \x{A9}2003 Kevin Davis
-layer at (439,302) size 180x16
- RenderBlock {DIV} at (2,3) size 180x16
-layer at (439,326) size 180x16
- RenderBlock {DIV} at (2,3) size 180x16
layer at (112,789) size 506x106 clip at (113,790) size 504x104
RenderTextControl {TEXTAREA} at (0,517) size 506x106
[bgcolor=#FF] [border: (1px solid #00)]
RenderBlock {DIV} at (3,3) size 500x16
The difference is only about layers being removed and RenderObject
being put back where they belong in the tree. There should be *no
change in the size of position of your RenderObject's* as they move.
Any change is a regression.
Feel free to pull me in on anything related to this rebaseline, I
would happily review or comment on any bug related.
Thanks,
Julien
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] git.webkit.org problem
Hi Lucas, Thank you very much for your answer! One change that was applied to Chromium's build bot console[1] recently was to cache the overview page for a minute. This may be relevant to the Apache caching layer you mentioned. If requests are really handled serially then updating to version 0.8.5 would hopefully yield performance improvements as well. Peter [1] http://chromium-build-master.appspot.com/p/chromium/console On Wed, Feb 29, 2012 at 19:32, Lucas Forschler lforsch...@apple.com wrote: Hi Peter, I am looking into improving performance of build.webkit.org. After doing some initial research I feel that buildbot isn't the most efficient in terms of processing a large number of requests. I believe requests are processed serially, and not in parallel. The buildbot documentation mentions a limit to the number of slaves that can be supported, but doesn't give any specific numbers. As webkit has grown, and the number of builds and slaves we are supporting has increased, it seems the server is showing signs of reaching this capacity. We may have reached a limit on the number of slaves we can handle with our current configuration. Some of the things I have been researching to increase build.webkit.orgperformance include the following: -Upgrades to hardware. It's possible faster hardware could alleviate some problems. It is unclear if this is really the limiting factor, or how much additional capacity this would provide. -Updating the way files are transferred (https://bugs.webkit.org/show_bug.cgi?id=73484) -Upgrade the version of buildbot. (0.8.3 - 0.8.5). Version 0.8.4 and higher supposedly has a threading improvement, but it's unclear how much it would benefit us since it looks to be mostly database related. -Upgrading the version of twisted running on the sever. We are currently at version 8.2, and version 12 is now available. -Investigating some kind of apache caching layer on top of buildbot -Adding a second master to the buildbot system. buildbot supports multi-master mode. We could potentially split out build and test onto two separate masters. build.webkit.org and test.webkit.org ? I would be interested in hearing any other thoughts on increasing build.webkit.org performance. Lucas On Feb 29, 2012, at 7:08 AM, Peter Beverloo wrote: Hi Bill, Would it be possible to get some more information on your/Lucas' plans on improving stability of the infrastructure? This was the third significant interruption within a week, and especially for us non-PST folks it's becoming quite inconvenient. Thanks, Peter On Wed, Feb 29, 2012 at 15:00, William Siegrist wsiegr...@apple.comwrote: This should be fixed now. -Bill On Feb 29, 2012, at 3:19 AM, David Barr wrote: Is it any trick to update my git-svn repo from svn? I set up my git svn repo about $http://trac.webkit.org/wiki/UsingGitWithWebKit : - git clone git://git.webkit.org/WebKit.git WebKit - git svn init --prefix=origin/ -T trunk http://svn.webkit.org/repository/webkit - git config --replace svn-remote.svn.fetch trunk:refs/remotes/origin/master Usually, the only missing step here is 'git svn fetch'. However, when I run that now I get: RA layer request failed: OPTIONS of 'http://svn.webkit.org/repository/webkit': could not connect to server (http://svn.webkit.org) at /Users/davidbarr/libexec/git-core/git-svn line 2139 -- David Barr. ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] git.webkit.org problem
On Wed, Feb 29, 2012 at 11:32 AM, Lucas Forschler lforsch...@apple.comwrote: I am looking into improving performance of build.webkit.org. After doing some initial research I feel that buildbot isn't the most efficient in terms of processing a large number of requests. I believe requests are processed serially, and not in parallel. The buildbot documentation mentions a limit to the number of slaves that can be supported, but doesn't give any specific numbers. As webkit has grown, and the number of builds and slaves we are supporting has increased, it seems the server is showing signs of reaching this capacity. We may have reached a limit on the number of slaves we can handle with our current configuration. On Chromium side, buildbot appears to leak a great amount of memory. e.g. we end up running out of memory at some point because buildbot keeps leaking some memory over time :( Do you see the same issue on your buildbot? -Upgrades to hardware. It's possible faster hardware could alleviate some problems. It is unclear if this is really the limiting factor, or how much additional capacity this would provide. My understanding is that we use a really fast server but still experience a similar problem. -Updating the way files are transferred (https://bugs.webkit.org/show_bug.cgi?id=73484) Would it make sense to have a separate apache server, etc... for receiving these files? twistd doesn't appear to be a cut out for uploading/downloading megabytes of data. -Upgrade the version of buildbot. (0.8.3 - 0.8.5). Version 0.8.4 and higher supposedly has a threading improvement, but it's unclear how much it would benefit us since it looks to be mostly database related. I've been told that upgrading buildbot didn't improve the performance. But upgrading it to 0.8.5 is probably a good nonetheless since it fixes various bugs I've encountered while maintaining Chromium bots and also when I ran buildbot locally. -Investigating some kind of apache caching layer on top of buildbot MUST DO THIS. This will greatly reduce the latency for most people. -Adding a second master to the buildbot system. buildbot supports multi-master mode. We could potentially split out build and test onto two separate masters. build.webkit.org and test.webkit.org ? build.chromium.org takes this approach. But then we won't be able to see both build and test step at once though... Would it make more sense to split per port? e.g. Apple Mac Apple Win, Qt Gtk, Chromium misc or something along that line? - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] git.webkit.org problem
On Wed, Feb 29, 2012 at 3:38 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Feb 29, 2012 at 11:32 AM, Lucas Forschler lforsch...@apple.comwrote: I am looking into improving performance of build.webkit.org. After doing some initial research I feel that buildbot isn't the most efficient in terms of processing a large number of requests. I believe requests are processed serially, and not in parallel. The buildbot documentation mentions a limit to the number of slaves that can be supported, but doesn't give any specific numbers. As webkit has grown, and the number of builds and slaves we are supporting has increased, it seems the server is showing signs of reaching this capacity. We may have reached a limit on the number of slaves we can handle with our current configuration. On Chromium side, buildbot appears to leak a great amount of memory. e.g. we end up running out of memory at some point because buildbot keeps leaking some memory over time :( Do you see the same issue on your buildbot? -Upgrades to hardware. It's possible faster hardware could alleviate some problems. It is unclear if this is really the limiting factor, or how much additional capacity this would provide. My understanding is that we use a really fast server but still experience a similar problem. -Updating the way files are transferred (https://bugs.webkit.org/show_bug.cgi?id=73484) Would it make sense to have a separate apache server, etc... for receiving these files? twistd doesn't appear to be a cut out for uploading/downloading megabytes of data. -Upgrade the version of buildbot. (0.8.3 - 0.8.5). Version 0.8.4 and higher supposedly has a threading improvement, but it's unclear how much it would benefit us since it looks to be mostly database related. I've been told that upgrading buildbot didn't improve the performance. But upgrading it to 0.8.5 is probably a good nonetheless since it fixes various bugs I've encountered while maintaining Chromium bots and also when I ran buildbot locally. -Investigating some kind of apache caching layer on top of buildbot MUST DO THIS. This will greatly reduce the latency for most people. -Adding a second master to the buildbot system. buildbot supports multi-master mode. We could potentially split out build and test onto two separate masters. build.webkit.org and test.webkit.org ? build.chromium.org takes this approach. But then we won't be able to see both build and test step at once though... Would it make more sense to split per port? e.g. Apple Mac Apple Win, Qt Gtk, Chromium misc or something along that line? If this is pursued, then I would tend to agree with a per-port split vs a vertical split. But, it would mean more masters and more places to keep an eye on when doing cross-port changes, which could get out of hand. - Ryosuke ___ 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] spinoff from webkit-patch -g discussion
Quote from the discussion: that's why I said that having something like webkit-patch upload range_of_commits will be nice to have, as you wouldn't have to create a new branch and rebase several commits, just to upload a new patch to the bz. You can do this with the current -g option by adding a commit range, e.g. -g=commit1..commit2. AFAIK, the only thing you can't do currently with -g is pass a commit range *and* include the staged/working copy changes. Under the hood it basically does what you described (create a new branch, copy the commits over as a single commit, upload from the branch, etc). I didn't want to hikack the other thread, but I wanted to discuss this -git-commit flag. It makes sense that we can't commit a commit range + unstaged changes, and its easy enough to commit before uploading. However, one problem I've encountered is that webkit-patch may make changes to the changelogs, in particular the reviewed by clause. But then, because its an unstaged change, it uploads the reviewed by nobody clause. So I have to manually edit the reviewed by... statement, commit, and then upload. Am I missing something simple? It seems to defeat the purpose of automatically editing the changelogs, if I still have to quit and commit it myself before uploading again. Would it be reasonable to force an error to upload a commit range, when there are unstaged changes? I've observed this only for land-safely and upload. I've been unwilling to experiment with landing directly because I don't want it to accidentally commit a reviewed by nobody to the changelogs. Thanks, ~Shawn ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] spinoff from webkit-patch -g discussion
On Wed, Feb 29, 2012 at 3:06 PM, Shawn Singh shawnsi...@chromium.org wrote: Quote from the discussion: that's why I said that having something like webkit-patch upload range_of_commits will be nice to have, as you wouldn't have to create a new branch and rebase several commits, just to upload a new patch to the bz. You can do this with the current -g option by adding a commit range, e.g. -g=commit1..commit2. AFAIK, the only thing you can't do currently with -g is pass a commit range *and* include the staged/working copy changes. Under the hood it basically does what you described (create a new branch, copy the commits over as a single commit, upload from the branch, etc). I didn't want to hikack the other thread, but I wanted to discuss this -git-commit flag. It makes sense that we can't commit a commit range + unstaged changes, and its easy enough to commit before uploading. However, one problem I've encountered is that webkit-patch may make changes to the changelogs, in particular the reviewed by clause. But then, because its an unstaged change, it uploads the reviewed by nobody clause. So I have to manually edit the reviewed by... statement, commit, and then upload. Am I missing something simple? It seems to defeat the purpose of automatically editing the changelogs, if I still have to quit and commit it myself before uploading again. No, you are not missing something; this is actually one of the main reasons I started the thread. Would it be reasonable to force an error to upload a commit range, when there are unstaged changes? I've observed this only for land-safely and upload. I've been unwilling to experiment with landing directly because I don't want it to accidentally commit a reviewed by nobody to the changelogs. In my view, I would actually rather upload the combination of committed + staged + unstaged changes rather than be told I have to commit things; in other words, I actually prefer to commit what I've uploaded rather than upload what I've committed. landing directly shouldn't be an an issue, insofar as webkit-patch will stop (or at least warn) you if you still have an OOPS in the Changelog. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] git.webkit.org problem
I'm currenlty upgrading build.webkit.org from 0.8.3 to 0.8.5. It should be back online shortly. Lucas On Feb 29, 2012, at 12:38 PM, Ryosuke Niwa wrote: On Wed, Feb 29, 2012 at 11:32 AM, Lucas Forschler lforsch...@apple.com wrote: I am looking into improving performance of build.webkit.org. After doing some initial research I feel that buildbot isn't the most efficient in terms of processing a large number of requests. I believe requests are processed serially, and not in parallel. The buildbot documentation mentions a limit to the number of slaves that can be supported, but doesn't give any specific numbers. As webkit has grown, and the number of builds and slaves we are supporting has increased, it seems the server is showing signs of reaching this capacity. We may have reached a limit on the number of slaves we can handle with our current configuration. On Chromium side, buildbot appears to leak a great amount of memory. e.g. we end up running out of memory at some point because buildbot keeps leaking some memory over time :( Do you see the same issue on your buildbot? -Upgrades to hardware. It's possible faster hardware could alleviate some problems. It is unclear if this is really the limiting factor, or how much additional capacity this would provide. My understanding is that we use a really fast server but still experience a similar problem. -Updating the way files are transferred (https://bugs.webkit.org/show_bug.cgi?id=73484) Would it make sense to have a separate apache server, etc... for receiving these files? twistd doesn't appear to be a cut out for uploading/downloading megabytes of data. -Upgrade the version of buildbot. (0.8.3 - 0.8.5). Version 0.8.4 and higher supposedly has a threading improvement, but it's unclear how much it would benefit us since it looks to be mostly database related. I've been told that upgrading buildbot didn't improve the performance. But upgrading it to 0.8.5 is probably a good nonetheless since it fixes various bugs I've encountered while maintaining Chromium bots and also when I ran buildbot locally. -Investigating some kind of apache caching layer on top of buildbot MUST DO THIS. This will greatly reduce the latency for most people. -Adding a second master to the buildbot system. buildbot supports multi-master mode. We could potentially split out build and test onto two separate masters. build.webkit.org and test.webkit.org ? build.chromium.org takes this approach. But then we won't be able to see both build and test step at once though... Would it make more sense to split per port? e.g. Apple Mac Apple Win, Qt Gtk, Chromium misc or something along that line? - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] spinoff from webkit-patch -g discussion
Awesome thanks very much. =) Yeah, the way you proposed to deal with it seems better, now I think of it. ~Shawn On Wed, Feb 29, 2012 at 4:33 PM, Shawn Singh shawnsi...@google.com wrote: Awesome thanks very much. =) Yeah, the way you proposed to deal with it seems better, now I think of it. ~Shawn On Wed, Feb 29, 2012 at 3:28 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, Feb 29, 2012 at 3:06 PM, Shawn Singh shawnsi...@chromium.org wrote: Quote from the discussion: that's why I said that having something like webkit-patch upload range_of_commits will be nice to have, as you wouldn't have to create a new branch and rebase several commits, just to upload a new patch to the bz. You can do this with the current -g option by adding a commit range, e.g. -g=commit1..commit2. AFAIK, the only thing you can't do currently with -g is pass a commit range *and* include the staged/working copy changes. Under the hood it basically does what you described (create a new branch, copy the commits over as a single commit, upload from the branch, etc). I didn't want to hikack the other thread, but I wanted to discuss this -git-commit flag. It makes sense that we can't commit a commit range + unstaged changes, and its easy enough to commit before uploading. However, one problem I've encountered is that webkit-patch may make changes to the changelogs, in particular the reviewed by clause. But then, because its an unstaged change, it uploads the reviewed by nobody clause. So I have to manually edit the reviewed by... statement, commit, and then upload. Am I missing something simple? It seems to defeat the purpose of automatically editing the changelogs, if I still have to quit and commit it myself before uploading again. No, you are not missing something; this is actually one of the main reasons I started the thread. Would it be reasonable to force an error to upload a commit range, when there are unstaged changes? I've observed this only for land-safely and upload. I've been unwilling to experiment with landing directly because I don't want it to accidentally commit a reviewed by nobody to the changelogs. In my view, I would actually rather upload the combination of committed + staged + unstaged changes rather than be told I have to commit things; in other words, I actually prefer to commit what I've uploaded rather than upload what I've committed. landing directly shouldn't be an an issue, insofar as webkit-patch will stop (or at least warn) you if you still have an OOPS in the Changelog. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] git.webkit.org problem
build.webkit.org should be back online now with 0.8.5. Thanks for your patience! Lucas On Feb 29, 2012, at 3:44 PM, Lucas Forschler wrote: I'm currenlty upgrading build.webkit.org from 0.8.3 to 0.8.5. It should be back online shortly. Lucas On Feb 29, 2012, at 12:38 PM, Ryosuke Niwa wrote: On Wed, Feb 29, 2012 at 11:32 AM, Lucas Forschler lforsch...@apple.com wrote: I am looking into improving performance of build.webkit.org. After doing some initial research I feel that buildbot isn't the most efficient in terms of processing a large number of requests. I believe requests are processed serially, and not in parallel. The buildbot documentation mentions a limit to the number of slaves that can be supported, but doesn't give any specific numbers. As webkit has grown, and the number of builds and slaves we are supporting has increased, it seems the server is showing signs of reaching this capacity. We may have reached a limit on the number of slaves we can handle with our current configuration. On Chromium side, buildbot appears to leak a great amount of memory. e.g. we end up running out of memory at some point because buildbot keeps leaking some memory over time :( Do you see the same issue on your buildbot? -Upgrades to hardware. It's possible faster hardware could alleviate some problems. It is unclear if this is really the limiting factor, or how much additional capacity this would provide. My understanding is that we use a really fast server but still experience a similar problem. -Updating the way files are transferred (https://bugs.webkit.org/show_bug.cgi?id=73484) Would it make sense to have a separate apache server, etc... for receiving these files? twistd doesn't appear to be a cut out for uploading/downloading megabytes of data. -Upgrade the version of buildbot. (0.8.3 - 0.8.5). Version 0.8.4 and higher supposedly has a threading improvement, but it's unclear how much it would benefit us since it looks to be mostly database related. I've been told that upgrading buildbot didn't improve the performance. But upgrading it to 0.8.5 is probably a good nonetheless since it fixes various bugs I've encountered while maintaining Chromium bots and also when I ran buildbot locally. -Investigating some kind of apache caching layer on top of buildbot MUST DO THIS. This will greatly reduce the latency for most people. -Adding a second master to the buildbot system. buildbot supports multi-master mode. We could potentially split out build and test onto two separate masters. build.webkit.org and test.webkit.org ? build.chromium.org takes this approach. But then we won't be able to see both build and test step at once though... Would it make more sense to split per port? e.g. Apple Mac Apple Win, Qt Gtk, Chromium misc or something along that line? - Ryosuke ___ 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] git.webkit.org problem
On 2012-02-29, at 17:05, Lucas Forschler lforsch...@apple.com wrote: build.webkit.org should be back online now with 0.8.5. Thanks for your patience! For anyone following along at home, upgrading to Buildbot v0.8.5 alone actually made build.webkit.org substantially slower. After profiling it for a while we noticed that it was spending an exceptionally long time performing queries against its SQLite database. Some analysis on the queries that were being run showed that the database lacked appropriate indices for the queries, causing full table scans across rather large tables. Ouch. A few CREATE INDEX … statements later and now build.webkit.org is responding much more quickly than it has been in quite some time. If anyone notices any bad behavior that they suspect may be related to this upgrade, please let us know. - Mark. Lucas On Feb 29, 2012, at 3:44 PM, Lucas Forschler wrote: I'm currenlty upgrading build.webkit.org from 0.8.3 to 0.8.5. It should be back online shortly. Lucas On Feb 29, 2012, at 12:38 PM, Ryosuke Niwa wrote: On Wed, Feb 29, 2012 at 11:32 AM, Lucas Forschler lforsch...@apple.com wrote: I am looking into improving performance of build.webkit.org. After doing some initial research I feel that buildbot isn't the most efficient in terms of processing a large number of requests. I believe requests are processed serially, and not in parallel. The buildbot documentation mentions a limit to the number of slaves that can be supported, but doesn't give any specific numbers. As webkit has grown, and the number of builds and slaves we are supporting has increased, it seems the server is showing signs of reaching this capacity. We may have reached a limit on the number of slaves we can handle with our current configuration. On Chromium side, buildbot appears to leak a great amount of memory. e.g. we end up running out of memory at some point because buildbot keeps leaking some memory over time :( Do you see the same issue on your buildbot? -Upgrades to hardware. It's possible faster hardware could alleviate some problems. It is unclear if this is really the limiting factor, or how much additional capacity this would provide. My understanding is that we use a really fast server but still experience a similar problem. -Updating the way files are transferred (https://bugs.webkit.org/show_bug.cgi?id=73484) Would it make sense to have a separate apache server, etc... for receiving these files? twistd doesn't appear to be a cut out for uploading/downloading megabytes of data. -Upgrade the version of buildbot. (0.8.3 - 0.8.5). Version 0.8.4 and higher supposedly has a threading improvement, but it's unclear how much it would benefit us since it looks to be mostly database related. I've been told that upgrading buildbot didn't improve the performance. But upgrading it to 0.8.5 is probably a good nonetheless since it fixes various bugs I've encountered while maintaining Chromium bots and also when I ran buildbot locally. -Investigating some kind of apache caching layer on top of buildbot MUST DO THIS. This will greatly reduce the latency for most people. -Adding a second master to the buildbot system. buildbot supports multi-master mode. We could potentially split out build and test onto two separate masters. build.webkit.org and test.webkit.org ? build.chromium.org takes this approach. But then we won't be able to see both build and test step at once though... Would it make more sense to split per port? e.g. Apple Mac Apple Win, Qt Gtk, Chromium misc or something along that line? - Ryosuke ___ 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] git.webkit.org problem
On Wed, Feb 29, 2012 at 6:10 PM, Mark Rowe mr...@apple.com wrote: On 2012-02-29, at 17:05, Lucas Forschler lforsch...@apple.com wrote: build.webkit.org should be back online now with 0.8.5. Thanks for your patience! For anyone following along at home, upgrading to Buildbot v0.8.5 alone actually made build.webkit.org substantially slower. After profiling it for a while we noticed that it was spending an exceptionally long time performing queries against its SQLite database. Some analysis on the queries that were being run showed that the database lacked appropriate indices for the queries, causing full table scans across rather large tables. Ouch. A few CREATE INDEX … statements later and now build.webkit.org is responding much more quickly than it has been in quite some time. If anyone notices any bad behavior that they suspect may be related to this upgrade, please let us know. svn.webkit.org (and trac) appears to be very unhappy at the moment; seems like this is likely related? -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] git.webkit.org problem
On 2012-02-29, at 18:20, Dirk Pranke dpra...@chromium.org wrote: On Wed, Feb 29, 2012 at 6:10 PM, Mark Rowe mr...@apple.com wrote: On 2012-02-29, at 17:05, Lucas Forschler lforsch...@apple.com wrote: build.webkit.org should be back online now with 0.8.5. Thanks for your patience! For anyone following along at home, upgrading to Buildbot v0.8.5 alone actually made build.webkit.org substantially slower. After profiling it for a while we noticed that it was spending an exceptionally long time performing queries against its SQLite database. Some analysis on the queries that were being run showed that the database lacked appropriate indices for the queries, causing full table scans across rather large tables. Ouch. A few CREATE INDEX … statements later and now build.webkit.org is responding much more quickly than it has been in quite some time. If anyone notices any bad behavior that they suspect may be related to this upgrade, please let us know. svn.webkit.org (and trac) appears to be very unhappy at the moment; seems like this is likely related? It may be that svn.webkit.org is unhappy about the thundering herd of reconnecting build slaves after the downtime. We'll look in to it. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] git.webkit.org problem
On Feb 29, 2012, at 6:22 PM, Mark Rowe wrote: On 2012-02-29, at 18:20, Dirk Pranke dpra...@chromium.org wrote: On Wed, Feb 29, 2012 at 6:10 PM, Mark Rowe mr...@apple.com wrote: On 2012-02-29, at 17:05, Lucas Forschler lforsch...@apple.com wrote: build.webkit.org should be back online now with 0.8.5. Thanks for your patience! For anyone following along at home, upgrading to Buildbot v0.8.5 alone actually made build.webkit.org substantially slower. After profiling it for a while we noticed that it was spending an exceptionally long time performing queries against its SQLite database. Some analysis on the queries that were being run showed that the database lacked appropriate indices for the queries, causing full table scans across rather large tables. Ouch. A few CREATE INDEX … statements later and now build.webkit.org is responding much more quickly than it has been in quite some time. If anyone notices any bad behavior that they suspect may be related to this upgrade, please let us know. svn.webkit.org (and trac) appears to be very unhappy at the moment; seems like this is likely related? It may be that svn.webkit.org is unhappy about the thundering herd of reconnecting build slaves after the downtime. We'll look in to it. I'm rebooting it again. I'm not sure if this is the same cause as the overnight problems or the slaves getting new checkouts. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] new: experimental support for 'virtual test suites' in new-run-webkit-tests
Hi all, I have recently landed support for 'virtual test suites' in new-run-webkit-tests (as the subject suggests ;) ). A virtual test suite tells NRWT to run all the tests in directory 'foo' with an additional set of command line arguments being passed to DRT, and to look for baselines in directory 'bar' before looking in directory 'foo'. As a concrete example, we're going to try and use this to remove the 'chromium-gpu' ports and just view gpu-specific tests as a virtual suite on top of the existing tests. So, we have a mapping that says: run all the tests in fast/canvas with --accelerated-2d-canvas being passed to DRT (as well as the normal flags), and look for results in LayoutTests/platform/chromium/virtual/gpu/fast/canvas before looking in the normal places. The mapping of virtual test suites is currently hardcoded in the NRWT python code (in the webkitpy/layout_tests/port/*.py files, to be precise), but it would be easy to make the mappings live as files in the tree as well. All of the normal tools (webkit-patch garden-o-matic, webkit-patch rebaseline, the flakiness dashboard) should work as if the virtual tests are regular tests. I doubt they do at the moment - I'm still testing and bug hunting. I believe this feature will be generally useful down the road. For example, one can imagine running a set of tests with a mocked-out set of controls (e.g., fake scrollbars) so that we can have platform-independent baselines, and then re-running a subset of the tests with native controls to ensure that they also work. I realize that this is a bit different than the normal practice for LayoutTests, where you often run tests differently by setting up a test differently and then including a SCRIPT to do the real test; the downside of the latter approach is that there's more boilerplate and you have to remember to do this every time a new test is added. That said, there are definitely still times (most times?) when that is the better approach. At any rate, like I said, it's an experiment and feedback is welcome. If you have ideas for how something like this might be useful but need additional features, etc., do let me know. Thanks, -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] git.webkit.org problem
On Feb 29, 2012, at 6:26 PM, William Siegrist wrote: On Feb 29, 2012, at 6:22 PM, Mark Rowe wrote: On 2012-02-29, at 18:20, Dirk Pranke dpra...@chromium.org wrote: On Wed, Feb 29, 2012 at 6:10 PM, Mark Rowe mr...@apple.com wrote: On 2012-02-29, at 17:05, Lucas Forschler lforsch...@apple.com wrote: If anyone notices any bad behavior that they suspect may be related to this upgrade, please let us know. svn.webkit.org (and trac) appears to be very unhappy at the moment; seems like this is likely related? It may be that svn.webkit.org is unhappy about the thundering herd of reconnecting build slaves after the downtime. We'll look in to it. I'm rebooting it again. I'm not sure if this is the same cause as the overnight problems or the slaves getting new checkouts. Our database pooling could not handle the frequent reboots of the clients, so I'm rebooting most of webkit.org to clean up the mess. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] git.webkit.org problem
On Feb 29, 2012, at 6:33 PM, William Siegrist wrote: On Feb 29, 2012, at 6:26 PM, William Siegrist wrote: On Feb 29, 2012, at 6:22 PM, Mark Rowe wrote: On 2012-02-29, at 18:20, Dirk Pranke dpra...@chromium.org wrote: On Wed, Feb 29, 2012 at 6:10 PM, Mark Rowe mr...@apple.com wrote: On 2012-02-29, at 17:05, Lucas Forschler lforsch...@apple.com wrote: If anyone notices any bad behavior that they suspect may be related to this upgrade, please let us know. svn.webkit.org (and trac) appears to be very unhappy at the moment; seems like this is likely related? It may be that svn.webkit.org is unhappy about the thundering herd of reconnecting build slaves after the downtime. We'll look in to it. I'm rebooting it again. I'm not sure if this is the same cause as the overnight problems or the slaves getting new checkouts. Our database pooling could not handle the frequent reboots of the clients, so I'm rebooting most of webkit.org to clean up the mess. And we're back up again. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] git.webkit.org problem
We're back to the slaves overloading svn. The Apple slaves are blocked temporarily while everyone else catches up. Sorry for the inconvenience. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] The Care and Feeding of WebCore Modules
Here's an update of my lists based on the notes from you, Adam and others: == Existing Modules == gamepad geolocation indexeddb (work in progress) intents mediastream vibration websockets == Likely Future Modules == filesystem notifications pagevisibility protocolhandler websql webaudio == Non-Modules Using Module-Related Techniques for Loose Coupling == devicemotion deviceoritentation html (seems to be agreement on reverting this) speechinput (seems to be agreement on keeping this) svg webgl workers xml == Possibly Planned Future Uses of Module Techniques for non-Modules == events -- Assuming this reflects up-to-date plans, I can put it in a wiki page, though I'm not sure I'll always be able to keep it up to date with changes of plans. I would suggest that, based on the discussion so far, html, svg, webgl, workers, and xml should be de-quasi-modularized at least for now. I would also suggest not applying Module techniques to DOM events, at least for now, unless I misunderstand the intent. devicemotion and deviceorientation seem to be using Supplement in a similar way and for a similar reason to speechinput, so I'd presume folks are ok with those. We may also want to consider whether websockets is truly a good candidate for the module treatment. It seems to me that at some point soon, if not already, it will be mature and accepted enough to be considered part of the core, though the code is relatively standalone. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] The Care and Feeding of WebCore Modules
On Wed, Feb 29, 2012 at 11:31 PM, Maciej Stachowiak m...@apple.com wrote: Here's an update of my lists based on the notes from you, Adam and others: == Existing Modules == gamepad geolocation indexeddb (work in progress) intents mediastream vibration websockets == Likely Future Modules == filesystem notifications pagevisibility protocolhandler websql webaudio == Non-Modules Using Module-Related Techniques for Loose Coupling == devicemotion deviceoritentation html (seems to be agreement on reverting this) speechinput (seems to be agreement on keeping this) svg webgl workers xml == Possibly Planned Future Uses of Module Techniques for non-Modules == events -- Assuming this reflects up-to-date plans, I can put it in a wiki page, though I'm not sure I'll always be able to keep it up to date with changes of plans. I would suggest that, based on the discussion so far, html, svg, webgl, workers, and xml should be de-quasi-modularized at least for now. I would also suggest not applying Module techniques to DOM events, at least for now, unless I misunderstand the intent. devicemotion and deviceorientation seem to be using Supplement in a similar way and for a similar reason to speechinput, so I'd presume folks are ok with those. We may also want to consider whether websockets is truly a good candidate for the module treatment. It seems to me that at some point soon, if not already, it will be mature and accepted enough to be considered part of the core, though the code is relatively standalone. That sounds like a good plan. One thing I'd say is that being a module doesn't mean a feature is any less important as a part of WebKit. It's just a way to structure the code. WebSQL is pretty mature, but that doesn't mean it needs to take up space in Document.cpp, for example. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] The Care and Feeding of WebCore Modules
Thank you very much for the organization. Your suggestion sounds great to me. Just for clarification, I would like to confirm what action we should take for each item from now: == Existing Modules == gamepad = KEEP geolocation = KEEP indexeddb (work in progress) = KEEP intents = KEEP mediastream = KEEP vibration = KEEP websockets = KEEP == Likely Future Modules == filesystem = DISCUSS BEFORE MODULARIZATION notifications = DISCUSS BEFORE MODULARIZATION pagevisibility = DISCUSS BEFORE MODULARIZATION protocolhandler = DISCUSS BEFORE MODULARIZATION websql = DISCUSS BEFORE MODULARIZATION webaudio = DISCUSS BEFORE MODULARIZATION == Non-Modules Using Module-Related Techniques for Loose Coupling == devicemotion = KEEP deviceoritentation = KEEP html (seems to be agreement on reverting this) = REVERT speechinput (seems to be agreement on keeping this) = KEEP svg = REVERT webgl = REVERT workers = REVERT xml = REVERT == Possibly Planned Future Uses of Module Techniques for non-Modules == events = WONT MODULARIZE If you have any concern, let's discuss here. If no objection, I'll start the above work from tomorrow. On Thu, Mar 1, 2012 at 4:31 PM, Maciej Stachowiak m...@apple.com wrote: Here's an update of my lists based on the notes from you, Adam and others: == Existing Modules == gamepad geolocation indexeddb (work in progress) intents mediastream vibration websockets == Likely Future Modules == filesystem notifications pagevisibility protocolhandler websql webaudio == Non-Modules Using Module-Related Techniques for Loose Coupling == devicemotion deviceoritentation html (seems to be agreement on reverting this) speechinput (seems to be agreement on keeping this) svg webgl workers xml == Possibly Planned Future Uses of Module Techniques for non-Modules == events -- Assuming this reflects up-to-date plans, I can put it in a wiki page, though I'm not sure I'll always be able to keep it up to date with changes of plans. I would suggest that, based on the discussion so far, html, svg, webgl, workers, and xml should be de-quasi-modularized at least for now. I would also suggest not applying Module techniques to DOM events, at least for now, unless I misunderstand the intent. devicemotion and deviceorientation seem to be using Supplement in a similar way and for a similar reason to speechinput, so I'd presume folks are ok with those. We may also want to consider whether websockets is truly a good candidate for the module treatment. It seems to me that at some point soon, if not already, it will be mature and accepted enough to be considered part of the core, though the code is relatively standalone. Regards, Maciej -- Kentaro Hara, Tokyo, Japan (http://haraken.info) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] The Care and Feeding of WebCore Modules
On Wed, Feb 29, 2012 at 11:49 PM, Kentaro Hara hara...@chromium.org wrote: Thank you very much for the organization. Your suggestion sounds great to me. Just for clarification, I would like to confirm what action we should take for each item from now: == Existing Modules == gamepad = KEEP geolocation = KEEP indexeddb (work in progress) = KEEP intents = KEEP mediastream = KEEP vibration = KEEP websockets = KEEP == Likely Future Modules == filesystem = DISCUSS BEFORE MODULARIZATION notifications = DISCUSS BEFORE MODULARIZATION pagevisibility = DISCUSS BEFORE MODULARIZATION protocolhandler = DISCUSS BEFORE MODULARIZATION websql = DISCUSS BEFORE MODULARIZATION webaudio = DISCUSS BEFORE MODULARIZATION ^^^ I'd like to modularize these two relatively soon. webaudio is basically done. We're just waiting for crogers to give us the thumbs up to move the files. As for websql, it seems very parallel to indexeddb and likely should be implemented using a similar approach. Adam == Non-Modules Using Module-Related Techniques for Loose Coupling == devicemotion = KEEP deviceoritentation = KEEP html (seems to be agreement on reverting this) = REVERT speechinput (seems to be agreement on keeping this) = KEEP svg = REVERT webgl = REVERT workers = REVERT xml = REVERT == Possibly Planned Future Uses of Module Techniques for non-Modules == events = WONT MODULARIZE If you have any concern, let's discuss here. If no objection, I'll start the above work from tomorrow. On Thu, Mar 1, 2012 at 4:31 PM, Maciej Stachowiak m...@apple.com wrote: Here's an update of my lists based on the notes from you, Adam and others: == Existing Modules == gamepad geolocation indexeddb (work in progress) intents mediastream vibration websockets == Likely Future Modules == filesystem notifications pagevisibility protocolhandler websql webaudio == Non-Modules Using Module-Related Techniques for Loose Coupling == devicemotion deviceoritentation html (seems to be agreement on reverting this) speechinput (seems to be agreement on keeping this) svg webgl workers xml == Possibly Planned Future Uses of Module Techniques for non-Modules == events -- Assuming this reflects up-to-date plans, I can put it in a wiki page, though I'm not sure I'll always be able to keep it up to date with changes of plans. I would suggest that, based on the discussion so far, html, svg, webgl, workers, and xml should be de-quasi-modularized at least for now. I would also suggest not applying Module techniques to DOM events, at least for now, unless I misunderstand the intent. devicemotion and deviceorientation seem to be using Supplement in a similar way and for a similar reason to speechinput, so I'd presume folks are ok with those. We may also want to consider whether websockets is truly a good candidate for the module treatment. It seems to me that at some point soon, if not already, it will be mature and accepted enough to be considered part of the core, though the code is relatively standalone. Regards, Maciej -- Kentaro Hara, Tokyo, Japan (http://haraken.info) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
