Currently, Samsung developers are trying to make better EFL port. So, we are trying to contribute our patches to trunk.
But, I think there is no efl special reviewers yet. Whenever we make a patch, we have requested to review to other reviewer(Kenneth, Antonio, tkent, eric, abarth and so on) and Profusion's developers via IRC. But, we should wait a little long time in order to review some patches. (Of course, Kenneth and Antonio have reviewed our patches well so far.) Of course, We're trying to review EFL patches by ourselves. But, it is not insufficient. EFL reviewers should review them. Currently, some EFL patches are still pending. I think EFL port should have reviewer certainly. And also, I'm trying to be a reviewer for EFL port. - Gyuyoung > The problem is that as I am not working on the port myself, I find it > quite hard to review their API's without getting input from someone > else working on EFL. > > I think Antonio feels likewise. > > Kenneth > > On Mon, Apr 11, 2011 at 2:13 AM, Antonio Gomes<toniki...@gmail.com> wrote: >> Mostly myself and Kenneth. We do what we can, but we also to work on our >> stuff (as everybody else :). It really needs other reviewers to help out >> with reviewing, since EFL port guys are working really hard on it. >> >> On Sun, Apr 10, 2011 at 7:51 PM, Eric Seidel<e...@webkit.org> wrote: >>> >>> We seem to have a zillion EFL patches up for review. >>> Who are the EFL reviewers? >>> (I think part of the trouble is that it seems the EFL port is trying to do >>> too much in WebKit. I'm not sure where the EFL browser is, but some of the >>> patches look like they should be re-directed to that project instead of >>> WebKit.) >>> -eric >>> _______________________________________________ >>> webkit-dev mailing list >>> webkit-dev@lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >> >> >> >> -- >> --Antonio Gomes >> -----Original Message----- From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev- boun...@lists.webkit.org] On Behalf Of webkit-dev-requ...@lists.webkit.org Sent: Monday, April 11, 2011 11:00 PM To: webkit-dev@lists.webkit.org Subject: webkit-dev Digest, Vol 71, Issue 10 Send webkit-dev mailing list submissions to webkit-dev@lists.webkit.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev or, via email, send a message with subject or body 'help' to webkit-dev-requ...@lists.webkit.org You can reach the person managing the list at webkit-dev-ow...@lists.webkit.org When replying, please edit your Subject line so it is more specific than "Re: Contents of webkit-dev digest..." Today's Topics: 1. Who are the EFL reviewers? (Eric Seidel) 2. Re: Who are the EFL reviewers? (Antonio Gomes) 3. How does webkit manage memory? (Corey Fu) 4. Re: webkit-dev Digest, Vol 71, Issue 8 (Gyuyoung Kim) 5. Re: Who are the EFL reviewers? (Kenneth Rohde Christiansen) 6. Re: Who are the EFL reviewers? (Tomasz Morawski) ---------------------------------------------------------------------- Message: 1 Date: Sun, 10 Apr 2011 16:51:16 -0700 From: Eric Seidel <e...@webkit.org> To: WebKit Development <webkit-dev@lists.webkit.org> Subject: [webkit-dev] Who are the EFL reviewers? Message-ID: <BANLkTi=12=hdbjmitemfl7js856y2jg...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" We seem to have a zillion EFL patches up for review. Who are the EFL reviewers? (I think part of the trouble is that it seems the EFL port is trying to do too much in WebKit. I'm not sure where the EFL browser is, but some of the patches look like they should be re-directed to that project instead of WebKit.) -eric -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit- dev/attachments/20110410/3482cca8/attachment-0001.html> ------------------------------ Message: 2 Date: Sun, 10 Apr 2011 20:13:48 -0400 From: Antonio Gomes <toniki...@gmail.com> To: Eric Seidel <e...@webkit.org> Cc: WebKit Development <webkit-dev@lists.webkit.org> Subject: Re: [webkit-dev] Who are the EFL reviewers? Message-ID: <banlktik-vdd+4kdyugzj5u67hpe31qj...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Mostly myself and Kenneth. We do what we can, but we also to work on our stuff (as everybody else :). It really needs other reviewers to help out with reviewing, since EFL port guys are working really hard on it. On Sun, Apr 10, 2011 at 7:51 PM, Eric Seidel <e...@webkit.org> wrote: > We seem to have a zillion EFL patches up for review. > > Who are the EFL reviewers? > > (I think part of the trouble is that it seems the EFL port is trying to do > too much in WebKit. I'm not sure where the EFL browser is, but some of the > patches look like they should be re-directed to that project instead of > WebKit.) > > -eric > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -- --Antonio Gomes -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit- dev/attachments/20110410/497726cd/attachment-0001.html> ------------------------------ Message: 3 Date: Mon, 11 Apr 2011 10:43:11 +0800 From: Corey Fu <core...@gmail.com> To: webkit-dev@lists.webkit.org Subject: [webkit-dev] How does webkit manage memory? Message-ID: <BANLkTimDM5DbmgqjXHRUABfszUx-+vzn=w...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" I notice that webkit consumes memory depending on the memory of my embedded machine offered but leaved about 2M memory, which is the result of system kernel(linux kernel) dispatch or webkit's memory manager mechanism?How does webkit manage memory? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit- dev/attachments/20110411/fe0fc09b/attachment-0001.html> ------------------------------ Message: 4 Date: Mon, 11 Apr 2011 11:45:39 +0900 From: Gyuyoung Kim <gyuyoung....@samsung.com> To: webkit-dev@lists.webkit.org Cc: 'Krzysztof Czech' <k.cz...@samsung.com>, '???' <sangseok....@samsung.com> Subject: Re: [webkit-dev] webkit-dev Digest, Vol 71, Issue 8 Message-ID: <02c901cbf7f2$8ad321f0$a07965d0$%k...@samsung.com> Content-Type: text/plain; charset=ks_c_5601-1987 > I know Samsung is using the feature but they're not sure if they'll be > supporting it in the future. Are there are other folks who are actively > using WML? We're using WML in WebKit trunk now. Even though, there are some maintenance difficulties, I think WML needs to be maintained for some time. BTW, as far as I know, there are some bugs in WML. So, we have plan to contribute our patches soon. - Gyuyoung Kim -----Original Message----- From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev- boun...@lists.webkit.org] On Behalf Of webkit-dev-requ...@lists.webkit.org Sent: Friday, April 08, 2011 11:00 PM To: webkit-dev@lists.webkit.org Subject: webkit-dev Digest, Vol 71, Issue 8 Send webkit-dev mailing list submissions to webkit-dev@lists.webkit.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev or, via email, send a message with subject or body 'help' to webkit-dev-requ...@lists.webkit.org You can reach the person managing the list at webkit-dev-ow...@lists.webkit.org When replying, please edit your Subject line so it is more specific than "Re: Contents of webkit-dev digest..." Today's Topics: 1. Re: Disallowing modal dialogs during unload events (Darin Fisher) 2. Re: Disallowing modal dialogs during unload events (Maciej Stachowiak) 3. Re: Disallowing modal dialogs during unload events (Sreeram Ramachandran) 4. Re: An update on new-run-webkit-tests (Dirk Pranke) 5. Re: Disallowing modal dialogs during unload events (Ojan Vafai) 6. Dropping support for WML? (Ryosuke Niwa) 7. Re: Dropping support for WML? (Ryosuke Niwa) ---------------------------------------------------------------------- Message: 1 Date: Thu, 7 Apr 2011 10:21:45 -0700 From: Darin Fisher <da...@chromium.org> To: Sreeram Ramachandran <sree...@google.com> Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Disallowing modal dialogs during unload events Message-ID: <banlktinrz1wwtb3h5goplhn1cg60gvn...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" As you know, I'm a very strong advocate of this change. I think even if other ports aren't interested in experimenting with this change at the current time, that we should proceed to experiment with it in Chromium. I would very much like us to have data about how many sites are impacted, so that we can share that with others. -Darin On Wed, Apr 6, 2011 at 4:37 PM, Sreeram Ramachandran <sree...@google.com>wrote: > We'd like to disallow modal dialogs (i.e., those arising from calls to > alert, confirm, prompt or showModalDialog) during unload events > (beforeunload, unload and pagehide) [1]. Chromium wants to do this > [2]. Since this affects web compatibility, I'd like to get agreement > from the other webkit ports as well. > > The benefits are: > + Fewer annoyances for users who are trying to leave a page. > + In the case of tab close, allows the browser to hide the tab before > it has finished running the unload or pagehide event handlers (doesn't > apply to beforeunload); gives the impression of better performance. > > This doesn't affect returning a non-null value from beforeunload; that > will still cause the browser to show the stay-or-leave dialog. We > think that is sufficient to satisfy legitimate needs to warn the user > about data loss, etc. > > Outside webkit, this has been discussed on whatwg, but without a > definite conclusion [3]. Firefox seems to be considering this as well > [4]. > > All in favour, say aye! > > [1] https://bugs.webkit.org/show_bug.cgi?id=56397 > [2] http://code.google.com/p/chromium/issues/detail?id=68780 > [3] > http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010- February/025080.html > [4] https://bugzilla.mozilla.org/show_bug.cgi?id=391834 > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit- dev/attachments/20110407/eb066bda/attachment-0001.html> ------------------------------ Message: 2 Date: Thu, 07 Apr 2011 10:54:00 -0700 From: Maciej Stachowiak <m...@apple.com> To: Sreeram Ramachandran <sree...@google.com> Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Disallowing modal dialogs during unload events Message-ID: <a12aef7c-e8f9-4e24-968f-189ed4f11...@apple.com> Content-Type: text/plain; CHARSET=US-ASCII Is there data on: - The user impact of modal dialogs being fired from before unload, unload or page hide - how often does this happen? - The Web compatibility impact of removing this functionality (are the sites that do it using it for seemingly legitimate reasons)? I can think of two ways to gather the data: 1) Add some form of opt-in tracking to see how often users hit a modal dialog during an unload event, and sites where this is done, so we could determine if it causes breakage. 2) Run automated Web crawlers to find this out. Since we have a potential tradeoff between Web compatibility and usability, it would be good to get some data so that we can weigh the tradeoff. Side note: when I see a dialog upon leaving a webpage, it is almost always the beforeunload dialog. I'm not sure I have ever seen a regular alert, prompt, confirm, or showModalDialog when leaving the page. This is part of why I'd like to see data. Would we be solving a real problem with this change, or just a theoretical one? Regards, Maciej On Apr 6, 2011, at 4:37 PM, Sreeram Ramachandran wrote: > We'd like to disallow modal dialogs (i.e., those arising from calls to > alert, confirm, prompt or showModalDialog) during unload events > (beforeunload, unload and pagehide) [1]. Chromium wants to do this > [2]. Since this affects web compatibility, I'd like to get agreement > from the other webkit ports as well. > > The benefits are: > + Fewer annoyances for users who are trying to leave a page. > + In the case of tab close, allows the browser to hide the tab before > it has finished running the unload or pagehide event handlers (doesn't > apply to beforeunload); gives the impression of better performance. > > This doesn't affect returning a non-null value from beforeunload; that > will still cause the browser to show the stay-or-leave dialog. We > think that is sufficient to satisfy legitimate needs to warn the user > about data loss, etc. > > Outside webkit, this has been discussed on whatwg, but without a > definite conclusion [3]. Firefox seems to be considering this as well > [4]. > > All in favour, say aye! > > [1] https://bugs.webkit.org/show_bug.cgi?id=56397 > [2] http://code.google.com/p/chromium/issues/detail?id=68780 > [3] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010- February/025080.html > [4] https://bugzilla.mozilla.org/show_bug.cgi?id=391834 > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ------------------------------ Message: 3 Date: Thu, 7 Apr 2011 11:31:00 -0700 From: Sreeram Ramachandran <sree...@google.com> To: Maciej Stachowiak <m...@apple.com> Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Disallowing modal dialogs during unload events Message-ID: <BANLkTi=_qe4zx_=nostjzfnthhnt1yx...@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On Thu, Apr 7, 2011 at 10:54, Maciej Stachowiak <m...@apple.com> wrote: > Is there data on: > - The user impact of modal dialogs being fired from before unload, unload or page hide - how often does this happen? > - The Web compatibility impact of removing this functionality (are the sites that do it using it for seemingly legitimate reasons)? Sorry, I don't have any data at the moment (actually, I don't even have any examples). > I can think of two ways to gather the data: > 1) Add some form of opt-in tracking to see how often users hit a modal dialog during an unload event, and sites where this is done, so we could determine if it causes breakage. We can collect aggregate stats from Chromium, but our privacy policy won't let us collect specific URLs or sites. So, even if we found that a very small percentage of users are affected by this, we won't be able to tell which sites they were on, or whether the dialogs were necessary or annoying. > 2) Run automated Web crawlers to find this out. I'll try, but static analysis of js is hard/impossible; but perhaps I'll be able to find at least a couple of examples. > Since we have a potential tradeoff between Web compatibility and usability, it would be good to get some data so that we can weigh the tradeoff. > > Side note: when I see a dialog upon leaving ?a webpage, it is almost always the beforeunload dialog. I'm not sure I have ever seen a regular alert, prompt, confirm, or showModalDialog when leaving the page. This is part of why I'd like to see data. Would we be solving a real problem with this change, or just a theoretical one? As agreed on #webkit, we'll proceed by enabling this in chromium and collecting some aggregate stats (for whatever that's worth), relying on bug reports to find any specific issues that arise. ------------------------------ Message: 4 Date: Thu, 7 Apr 2011 12:55:39 -0700 From: Dirk Pranke <dpra...@chromium.org> To: Maciej Stachowiak <m...@apple.com> Cc: WebKit-Dev <webkit-dev@lists.webkit.org> Subject: Re: [webkit-dev] An update on new-run-webkit-tests Message-ID: <BANLkTi=9+wqtf0ono5fptft5lrzxhw1...@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Hi Maciej, Thanks for clarifying your concerns. I will address them a little out-of-order, because I think we probably agree on the important things even if we disagree on the less-important or more theoretical things. First, as far as the "future" discoveries go, I agree we should try to fix as many of the known issues as possible before cutting over. It may be that many or all of them have already been fixed, as I still need to verify some of these bugs. I definitely think the best way forward is to get NRWT bots up and see how things are working in practice; that way we should have a lot of data to tell us about the pros and cons of each tool. That said, On Thu, Apr 7, 2011 at 4:40 AM, Maciej Stachowiak <m...@apple.com> wrote: > If the new test tool causes more failures, or worse yet causes more tests to give unpredictable results, then that makes our testing system worse. The main benefit of new-run-webkit-tests, as I understand it, is that it can run the tests a lot faster. But I don't think it's a good tradeoff to run the tests a lot faster on the buildbot, if the results we get will be less reliable. I'm actually kind of shocked that anyone would consider replacing the test script with one that is known to make our existing tests less reliable. > Ideally, a test harness is stable, consistent, fast, expose as many bugs as possible, and expose those bugs in a way that is as reproducible as possible, and we should be shooting for that. But, just as our code should be bug free but isn't, the test harness may not be able to be ideal either, at which point, you'll probably prioritize some aspects of its behavior over others. For example, ORWT runs the tests in the same order every time in a single thread, and uses a long timeout. This makes the tests results very stable and consistent at the cost of potentially hiding some bugs (tests getting slower but not actually timing out, or tests that depend on previous tests having run). NRWT, at least the way we run it by default in Chromium, uses a much shorter timeout and of course runs things in parallel. This exposes those bugs, at the cost of making things appear flakier. We have attempted to build tooling to help with this, because we generally value finding more bugs over completely stable test runs. For example, we have an entirely separate tool called the "flakiness dashboard" that can help track the behavior of tests over time. So, your "less reliable" might actually be my "finding more bugs" :) NRWT has at least a couple of hooks that ORWT does not for helping to tune to your desired preferences, and we can configure them on a port-by-port basis. > I don't really care why tests would turn flaky. It's entirely possible that these are bugs in the tests themselves, or in the code they are testing. That should still be fixed. Of course. I'm certainly not suggesting that we shouldn't fix bugs. But, practically speaking, obviously we are okay with some tests failing, because we list them in Skipped files today. It may be that some of those tests would pass under NRWT, and we don't know that, either (because NRWT re-uses the existing Skipped files as-is. At some point we might want to change this). You mentioned that the "main benefit" of NRWT is that it is faster, but another benefit is that you can classify the expected failures better using NRWT, and detect real changes in the failure. If a test that used to render pixels incorrectly now actually has a different render tree, we'll catch that. If it starts crashing, we'll catch that. ORWT only has "run and expect it to pass" or "Skip and potentially miss something changing". I think I actually consider this more useful than the speed improvements. > > Nor do I think that marking tests as flaky in the expectations file means we are not losing test coverage. If a test can randomly pass or fail, and we know that and the tool expects it, we are nonetheless not getting the benefit of learning when the test starts failing. See above. The data is all there, and it's somewhat a question of what you want to surface where. We have largely attempted to build tools that get the best of both worlds. Maybe this is partially a question of what you would like the main waterfall and consoles to tell you, and perhaps I do not fully understand how different ports would answer this question? -- Dirk ------------------------------ Message: 5 Date: Fri, 8 Apr 2011 18:14:24 +1000 From: Ojan Vafai <o...@chromium.org> To: Maciej Stachowiak <m...@apple.com> Cc: WebKit Development <webkit-dev@lists.webkit.org> Subject: Re: [webkit-dev] Disallowing modal dialogs during unload events Message-ID: <BANLkTinur6W044j8McwBhDiQgFb=vbm...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" On Fri, Apr 8, 2011 at 3:54 AM, Maciej Stachowiak <m...@apple.com> wrote: > Side note: when I see a dialog upon leaving a webpage, it is almost always > the beforeunload dialog. I'm not sure I have ever seen a regular alert, > prompt, confirm, or showModalDialog when leaving the page. This is part of > why I'd like to see data. Would we be solving a real problem with this > change, or just a theoretical one? > In addition to the theoretical user benefit, I've been such a strong proponent of this change because it would greatly simplify some of Chromium's cross-process communication during tab/browser close. So, as long as it doesn't hurt existing, legitimate sites, I'd still like to see this happen. I'm happy with the resolution of trying this out in Chromium and getting some statistics about how often we hit this in the real world. Ojan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit- dev/attachments/20110408/f9522b24/attachment-0001.html> ------------------------------ Message: 6 Date: Fri, 8 Apr 2011 12:09:36 +0300 From: Ryosuke Niwa <rn...@webkit.org> To: WebKit Development <webkit-dev@lists.webkit.org> Subject: [webkit-dev] Dropping support for WML? Message-ID: <BANLkTimtr=uejlauae+gpnwmgb1_h_1...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Greetings all, We have been discussing the possibility of dropping WML support in WebKit on IRC for a while now because 1. None of core ports (Mac, Windows, GTK, Qt, & Chromium) use it by default 2. Maintenance cost is high I know Samsung is using the feature but they're not sure if they'll be supporting it in the future. Are there are other folks who are actively using WML? Best regards. Ryosuke Niwa Software Engineer Google Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit- dev/attachments/20110408/b4ea7260/attachment-0001.html> ------------------------------ Message: 7 Date: Fri, 8 Apr 2011 04:12:32 -0700 From: Ryosuke Niwa <rn...@webkit.org> To: Dirk Schulze <d...@dschulze.com> Cc: WebKit Development <webkit-dev@lists.webkit.org> Subject: Re: [webkit-dev] Dropping support for WML? Message-ID: <BANLkTi=KrbO0M=C-OFB8rs=gnjy9jou...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" On Fri, Apr 8, 2011 at 3:01 AM, Dirk Schulze <d...@dschulze.com> wrote: > If you search in the ChangeLogs, you'll see that we still get bug fixes and > build fixes for WML. > As far as I checked, much of changes in WML are due to changes in Core DOM and other parts of WebCore. See http://trac.webkit.org/log/trunk/Source/WebCore/wml But it seems it is not the case for WML yet. Also, I am unsure if "None of > the core ports use it by defautl" is a strong argument here. > Do you use WML? I'm simply interested in statistics not arguments for or against the idea of dropping the feature because we're most likely going to talk about this at the contributor's meeting. - Ryosuke -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.webkit.org/pipermail/webkit- dev/attachments/20110408/297f278c/attachment-0001.html> ------------------------------ _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev End of webkit-dev Digest, Vol 71, Issue 8 ***************************************** ------------------------------ Message: 5 Date: Mon, 11 Apr 2011 09:54:25 +0200 From: Kenneth Rohde Christiansen <kenneth.christian...@gmail.com> To: Antonio Gomes <toniki...@gmail.com> Cc: WebKit Development <webkit-dev@lists.webkit.org> Subject: Re: [webkit-dev] Who are the EFL reviewers? Message-ID: <banlktin_tux9sow-kil_1y1h7athmvu...@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 The problem is that as I am not working on the port myself, I find it quite hard to review their API's without getting input from someone else working on EFL. I think Antonio feels likewise. Kenneth On Mon, Apr 11, 2011 at 2:13 AM, Antonio Gomes <toniki...@gmail.com> wrote: > Mostly myself and Kenneth. We do what we can, but we also to work on our > stuff (as everybody else :). It really needs other reviewers to help out > with reviewing, since EFL port guys are working really hard on it. > > On Sun, Apr 10, 2011 at 7:51 PM, Eric Seidel <e...@webkit.org> wrote: >> >> We seem to have a zillion EFL patches up for review. >> Who are the EFL reviewers? >> (I think part of the trouble is that it seems the EFL port is trying to do >> too much in WebKit. ?I'm not sure where the EFL browser is, but some of the >> patches look like they should be re-directed to that project instead of >> WebKit.) >> -eric >> _______________________________________________ >> 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 > > -- Kenneth Rohde Christiansen Senior Engineer Application and Service Frameworks, Nokia Danmark A/S Phone? +45 4093 0598 / E-mail kenneth.christiansen at gmail.com http://codeposts.blogspot.com ??? ------------------------------ Message: 6 Date: Mon, 11 Apr 2011 12:40:29 +0200 From: Tomasz Morawski <t.moraw...@samsung.com> To: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Who are the EFL reviewers? Message-ID: <4da2da9d.8010...@samsung.com> Content-Type: text/plain; charset=UTF-8; format=flowed Hi, Is it possible to promote some other peoples to reviewers in the EFL port? Tomasz > The problem is that as I am not working on the port myself, I find it > quite hard to review their API's without getting input from someone > else working on EFL. > > I think Antonio feels likewise. > > Kenneth > > On Mon, Apr 11, 2011 at 2:13 AM, Antonio Gomes<toniki...@gmail.com> wrote: >> Mostly myself and Kenneth. We do what we can, but we also to work on our >> stuff (as everybody else :). It really needs other reviewers to help out >> with reviewing, since EFL port guys are working really hard on it. >> >> On Sun, Apr 10, 2011 at 7:51 PM, Eric Seidel<e...@webkit.org> wrote: >>> >>> We seem to have a zillion EFL patches up for review. >>> Who are the EFL reviewers? >>> (I think part of the trouble is that it seems the EFL port is trying to do >>> too much in WebKit. I'm not sure where the EFL browser is, but some of the >>> patches look like they should be re-directed to that project instead of >>> WebKit.) >>> -eric >>> _______________________________________________ >>> 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 End of webkit-dev Digest, Vol 71, Issue 10 ****************************************** _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev