Re: [webkit-dev] Github vs. git.webkit.org
On 11/30/12 23:59 , Hajime Morrita wrote: It looks github supports mirroring by pulling a repo from official location. http://stackoverflow.com/questions/11370239/creating-an-official-github-mirror Ah, didn't know they provided that service, nice. I'm a bit worried about the sync delay though, as you say. Bill, what do you think about pushing the official SVN import to GitHub as well? tor arne So we might be able to rename the existing one and ask github to pull our git.webkit.org http://git.webkit.org repository into github/WebKit/webkit. Apparently Apache takes that way: https://github.com/apache The mirroring icon indicates kind of official-ness. I don't know how long their mirroring delay is, though. On Sat, Dec 1, 2012 at 12:07 AM, Tor Arne Vestbø tor.arne.ves...@digia.com mailto:tor.arne.ves...@digia.com wrote: On 11/28/12 16:55 , Adam Barth wrote: My sense is that the WebKit community would prefer that the hashes in GitHub match the hashes in git.webkit.org http://git.webkit.org so that folks can more easily move branches between the two. For my part, I've switched over to using GitHub exclusive of git.webkit.org http://git.webkit.org, so the the difference in hashes aren't an issue for me, but I can understand why they'd be problematic for other people. Yepp, agreed. Let's switch it over. After the force-push, would you still be able to push updates automatically? If so, you can switch the hashes whenever is convenient for you. (It might be nice to announce the date/time on this list so that folks aren't taken by surprise.) The mirror is also pushed to http://gitorious.org/webkit/__webkit http://gitorious.org/webkit/webkit, which I was planning to keep as is for now, so that would mean setting up an extra mirroring for the non-author-rewritten history :/ Also, the server I run this on has a somewhat uncertain future. With that in mind it's probably easier to just push directly from the same import that's pushed to git.webkit.org http://git.webkit.org, and make the GitHub mirror an official mirror? tor arne _ webkit-dev mailing list webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org http://lists.webkit.org/__mailman/listinfo/webkit-dev http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Github vs. git.webkit.org
On 11/28/12 16:55 , Adam Barth wrote: My sense is that the WebKit community would prefer that the hashes in GitHub match the hashes in git.webkit.org so that folks can more easily move branches between the two. For my part, I've switched over to using GitHub exclusive of git.webkit.org, so the the difference in hashes aren't an issue for me, but I can understand why they'd be problematic for other people. Yepp, agreed. Let's switch it over. After the force-push, would you still be able to push updates automatically? If so, you can switch the hashes whenever is convenient for you. (It might be nice to announce the date/time on this list so that folks aren't taken by surprise.) The mirror is also pushed to http://gitorious.org/webkit/webkit, which I was planning to keep as is for now, so that would mean setting up an extra mirroring for the non-author-rewritten history :/ Also, the server I run this on has a somewhat uncertain future. With that in mind it's probably easier to just push directly from the same import that's pushed to git.webkit.org, and make the GitHub mirror an official mirror? tor arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Github vs. git.webkit.org
On 11/25/12 1:12 , Adam Barth wrote: On Sat, Nov 24, 2012 at 1:53 PM, Gergely Kis gerg...@homejinni.com wrote: Yes, I saw that thread, but I got confused by this other thread: https://lists.webkit.org/pipermail/webkit-dev/2012-April/020339.html Here most of the participants seemed to agree that moving the 2 repositories to use the same SHA ids is the best course of action. Unfortunately, the folks who maintain the mirror don't appear to agree. Given that they've been gracious enough to let us use their mirror, it's hard for us to ask them to change how they run it. This is not accurate. I replied directly to you Adam based on the above mentioned thread, countering a few points from the thread, but closing off by saying that if the consensus was that syncing the mirrors was the way to go, I was perfectly fine with that too. I still am -- all it takes is someone letting me know when to stop pushing and to do the mentioned force-push. Tor Arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] github mirror
On 18.04.12 17:02, Simon Hausmann wrote: On Wednesday, April 18, 2012 06:53:46 AM ext Shezan Baig wrote: Hi WebKit, I've been using a fork of the following repo: https://github.com/WebKit/webkit However, yesterday there was discussion on #webkit that the SHA-1 checksums on this repo are different from repo at git.webkit.org, which means folks working on both need to have both versions checked out. I believe the reason for them being different is because in the github repo the commit author fields are resolved. That's correct. I'm the one running that mirror (along with the one at gitorious.org/webkit), and the import is done using an author-script that resolves author names and emails for a nicer history. The commit objects will be different, hence the different sha1s, but the tree and blob objects are the same. In what situation does this cause issues? I'd like to keep the github/gitorious mirror with proper author names, so is it perhaps an alternative to move the webkit.org mirror to use the same author script? (which can also be cleaned up an improved to take into account names from changlogs vs commit-queue, etc). tor arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] github mirror
On 24.04.12 15:55, ext Adam Roben wrote: Probably the biggest issue is for people who've been using git.webkit.org and now want to try out GitHub. Since the commits are distinct between the two repositories, they have to do a full clone to make the switch. Any idea why git is not smarter when pulling down the objects? tor arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] github mirror
On 24.04.12 16:04, ext Shezan Baig wrote: On Tue, Apr 24, 2012 at 9:55 AM, Adam Robenaro...@webkit.org wrote: In what situation does this cause issues? Probably the biggest issue is for people who've been using git.webkit.org and now want to try out GitHub. Since the commits are distinct between the two repositories, they have to do a full clone to make the switch. In theory though, these users should be able to just add a remote to their existing clone. Then it will just sync the commit objects, and not the trees and blobs. Not ideal, they would have two different 'masters', but still doable, and not *that* much of an overhead. Switching between the different masters should also be fast since the trees will be the same. Right, a fetch should ideally just pull down the commit objects, but it appears git does not have this optimization. If it did, I don't think the issue of two remote masters would be that big, since you would at some point likely transition to use one of the mirrors anyways. And if not, having multiple mirrors/remotes should be fine -- I'm using both the github and gitorious mirror without any issues. But I agree these two repos should probably merge sooner rather than later, just to avoid confusion for new users etc :) I would support that if it means cleaning up the author-script (which I'm happy to do), and using that on webkit.org. tor arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] An incremental approach (was Re: UPDATED Re: Version control survey)
On 11.03.12 00:08, Alp Toker wrote: The way I see it, a better mirror would address: *Author Names *The committer names don't have the full author name in the git mirror right now, just an SVN id. This info could be extracted out of a database or the ChangeLog message if one exists, during import. People switch companies and email addresses over time, so that would have to be accounted for. The mirrors at http://gitorious.org/webkit/webkit and https://github.com/webkit/webkit (same repo), use an author-script during the import to resolve author names based on the committers list. The script could be more intelligent and pick up author names from Patch by in the commit message or the changelog itself. *Layout and repo size * The git repository with full history is enormous. A proposal (or even better, proof of concept) for git repository layout where the 'heavy' generated paths are split out into git submodules separate from the source code would make me feel more comfortable with the whole idea. Also, should be possible to do a shallow clone of these yet still be able to commit and push back upstream (if git supports this, git experts?) I've done some prototyping on how to do a smaller mirror, using git submodules or tools such as git-annex or git-media. So far the issue is that if you want to commit to SVN using git-svn none of these techniques can be used, which makes the smaller mirror less useful. There was a thread on the git mailing list that mentioned the possibly of writing a git-fast-import/export backend to solve this, ie to lazily populate the layout-test results, but I haven't had time to look into that further. So the conclusion so far is that it's not feasible to keep an incremental SVN-mirror that does on-the-fly pruning of layout-test results (into submodules or similar) while still being usable with git-svn. Ideas welcome! tor arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
On 09.03.12 01:36, Aaron Boodman wrote: I think it would look the same, except for instead of monotonically increasing decimal numbers in the revision column, you'd see random hexadecimal ones (typically 6-8 digits long). It would be possible to use 'git describe' [1] to give something like this: r-110272-g19c9e9c7 If we tag the initial commit in the repository as 'r'. The number refers to the number of commits after the tag 'r'. We could optionally tag WebKit versions, and get something like: v525.19-12345-g19c9e9c7 Meaning 12345 commits after v525.19 was tagged. Doing the latter does not prevent the former, as you can use --match r to force the initial tag. tor arne [1] http://linux.die.net/man/1/git-describe On Thu, Mar 8, 2012 at 4:20 PM, Lucas Forschlerlforsch...@apple.com wrote: Could someone enlighten me on what this page would look like after a conversion to git? http://build.webkit.org/builders/Windows%20Debug%20%28Build%29?numbuilds=100 Lucas On Mar 8, 2012, at 3:22 PM, Dirk Pranke wrote: On Thu, Mar 8, 2012 at 2:37 PM, David Barrdavidb...@google.com wrote: The monotonic labels that Ryosuke desires are known in git language as generation numbers. If we maintain a canonical linear history going forward, they would also be unique as with Subversion. This could be a good reason to resurrect the relevant thread on the git mailing list. slightly-offtopic, but I had not heard of generation numbers before. Based on a cursory web-learning pass (*), it sounds like they're not quite the same thing as SVN revisions, since SVN revision numers are unique to a repo, and two revisions on two different branches may have the same generation number. Since we do actually keep branches in the master repo, this wouldn't quite be the same (although it might possibly be acceptable). Please correct me if I'm wrong ... -- Dirk (*) http://stackoverflow.com/questions/6702821/git-commit-generation-numbers ___ 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] Moving to Git?
On 08.03.12 22:25, Ryosuke Niwa wrote: That'll certainly be an improvement. I still dislike git hashes though. If someone implements such a script in webkit-patch and we can automatically assign svn-revision like numbers to all commits, I can be convinced to use git. Dunno about webkit-patch, but would make sense to roll into update-webkit. Regarding revision numbers, 'git describe' could help us give a common way to describe revisions with monotonically increasing revision numbers. tor arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Is converting pixel tests to reftests kosher for imported libraries?
On 08.03.12 01:57, Levi Weintraub wrote: On Wed, Mar 7, 2012 at 4:50 PM, Ryosuke Niwa rn...@webkit.org mailto:rn...@webkit.org wrote: On Wed, Mar 7, 2012 at 4:44 PM, Darin Fisher da...@chromium.org mailto:da...@chromium.org wrote: Hrm, if the test expectations are customized already for different ports of WebKit, then why not support replacing a PNG file with a HTML file that is intended to generate exactly the same result? How does this impair our ability to update the tests? (I realize that our current reftest system may not work like this. I'm not familiar with the details of how it works in fact, but it seems like it could be as simple as having an expected result that is a HTML file instead of a PNG file.) How do we know that we are testing what the test is intending to test after the conversion? e.g. it's possible to create a reference file that fails to catch certain bugs. This sums up my worry as well. I can imagine a bug causing a CSS test and its reference to fail in the same way, masking the failure. What if the reference is one line of text + image that represents the expected result? That way ports can share the associated png. tor arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
On 08.03.12 18:22, Geoffrey Garen wrote: Rather than asking for a switch to git by fiat, why not improve git and our git-related infrastructure to the point where people choose to switch naturally? The fact that many valuable contributors choose not to use git is sufficient proof that switching by fiat would be a bad idea. That's a good point. I'm curious though, what are the main sicking points? tor arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Some new coding style rules
On 04.08.10 20.04, Adam Roben wrote: On Aug 4, 2010, at 7:15 AM, Jeremy Orlow wrote: 2. ENABLE(FOO) #endif comments #if ENABLE(FOO) .. #endif // ENABLE(FOO) Shall we remove the comment, or require it explicitely in the style rules? I find these comments especially helpful when there are nested #ifs involved. I also find them helpful (though less so) when there are no nested #ifs, but a lot of code is between the #if/#endif. I don't find them useful when a whole file (either .h or .cpp) is compiled out. I agree, nested #ifs, especially when non-indented, are a lot easier to read with ending comments. Tor Arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bugzilla Triaged keyword
On 26.04.10 22.16, Andras Becsi wrote: As far as I know QtWebKit uses this keyword to indicate that the corresponding bug has been checked and prioritized based on its severity by a triaging group of two QtWebKit developers. https://trac.webkit.org/wiki/QtWebKitBugs#Triagingbugs That's correct. It's an attempt at using Bugzilla for all our bugs, and to manage them with some sense of control over what's there :) 2010-04-26 21:06 keltezéssel, Alexey Proskuryakov írta: There are bugs marked with Triaged keyword in Bugzilla now. Keyword description says Indicates that the bug was triaged according to the Bug Reporting Guidelines, and passed. What is the intended usage for this keyword? Who adds it, and what is it used for? From the description, the difference sounds just like the difference between UNCONFIRMED and NEW, and we never had a lot of use for that, other than indicating to the reporter that someone looked at the bug. You're right, it is similar to UNCONFIRMED/NEW. The reason for choosing a keyword was the inherit limitations of the status, eg. anyone with editbugs will default to NEW, you can't go back from UNCONFIRMED to NEW, and an ASSIGNED or REOPENED bug loses the state, etc. Tor Arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] changelog and patches
On 23/2/10 13:31 , Evan Martin wrote: Run WebKitTools/Scripts/resolve-ChangeLogs each time you rebase. Or run once: git config merge.changelog.driver resolve-ChangeLogs --merge-driver %O %A %B tor arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Increasing the number of cross-platform/port expected results
Hey all, A reoccurring problem when trying to maintain layout-test results is differences in font and theme metrics for tests that dump the render tree. Often a test does not actually test font loading/rendering or theming, but has a piece of text or an input element somewhere in the test which causes the metrics in the render tree to be different, and hence the test failing. We're seeing this in the Qt port when results are checked in as platform-independent and causing failures, or when we have to generate platform-dependent results for new tests when the test looks cross-platform. I also had this problem when trying to get a Windows build up and running with 0 failing layout-tests, so that I could verify that I didn't break anything before landing. Even after using various tricks to get the same font setup as the buildbots I still had failures that looked like they were due to font metrics [1]. Lately we've been playing with the idea of using SVG fonts for the Qt port to get the same set of expected results for qt-mac, qt-linux and qt-win, by injecting new @font-face rules using a user-stylesheet and preventing platform-fonts from being loaded, but this approach/hack has proven to be quite fragile, and we will also miss out on those tests that actually test font loading/rendering. Another approach would be to use a fixed set of metrics for text and themes when running the DRT, unless the test specifically asks for real font and theme metrics. We could for example add two additional functions to the layout-test controller: layoutTestController.dumpRealFontMetrics() and layoutTestController.dumpRealThemeMetrics() This would allow us to share render-tree results between all ports for those tests that don't explicitly test font or theme rendering (unless I missed more platform-differences). Thoughts? Will this work? :) Or, are there other ways we could achieve the same thing? My worry is basically that the number of platform-specific-result will not scale as the number of ports and platforms increases if we continue to have all these false positive platform-specific-results that are not really platform-specific. Tor Arne [1] http://trac.webkit.org/wiki/BuildingOnWindows#RunningtheLayoutTestsonWindows ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Increasing the number of cross-platform/port expected results
On 23/2/10 14:15 , Evan Martin wrote: On Tue, Feb 23, 2010 at 2:00 PM, Tor Arne Vestbø tor.arne.ves...@nokia.com wrote: Lately we've been playing with the idea of using SVG fonts for the Qt port to get the same set of expected results for qt-mac, qt-linux and qt-win, by injecting new @font-face rules using a user-stylesheet and preventing platform-fonts from being loaded, but this approach/hack has proven to be quite fragile, and we will also miss out on those tests that actually test font loading/rendering. For Chromium on Linux, we try to insulate ourselves from the platform settings by injecting a custom fontconfig file and font list that makes things match Windows behavior. (Matching Windows is important because many sites will hardcode a pixel width on a div then fill it with text and expect the text not to wrap.) We do the same thing for the Qt DRT on Linux, but I was hoping to get something that would work for Windows and Mac OS X too, since we don't use FreeType on those platforms, etc. That's where the idea of using SVG fonts spawned, since if we force the Qt DRT to use the raster paint engine those SVG fonts should be rendered the same way regardless of platform. But then we would have the problem of not being able to test actual font loading (without adding lots of exceptions) and the trick would not work for other ports, just the Qt port. That's why I was playing with the idea of using hard-coded metrics for fonts and themes on a global basis in WebKit (if running under the DRT), and letting those tests that actually test font loading/rendering or theming override this using the layoutTestController. Does that sound achievable/desirable at all? :) tor arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Increasing the number of cross-platform/port expected results
On 23/2/10 17:02 , Simon Fraser wrote: On Feb 23, 2010, at 5:00 AM, Tor Arne Vestbø wrote: Hey all, A reoccurring problem when trying to maintain layout-test results is differences in font and theme metrics for tests that dump the render tree. Often a test does not actually test font loading/rendering or theming, but has a piece of text or an input element somewhere in the test which causes the metrics in the render tree to be different, and hence the test failing. I think the correct longterm solution to this problem is to use reftests. A reftest consists of two files; the test file, and a reference file that should give the same on-screen rendering. When the test is run, the browser loads both files, takes snapshots, and does a pixel comparison. Thus font differences between platforms become less of an issue. You mean for example that the reference file of a css-border test that has some header-text describing the test would contain the same header-text but then a image to represent the reference of the css-part? tor arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Increasing the number of cross-platform/port expected results
On 23/2/10 17:34 , Simon Fraser wrote: On Feb 23, 2010, at 8:21 AM, Tor Arne Vestbø wrote: On 23/2/10 17:02 , Simon Fraser wrote: I think the correct longterm solution to this problem is to use reftests. A reftest consists of two files; the test file, and a reference file that should give the same on-screen rendering. When the test is run, the browser loads both files, takes snapshots, and does a pixel comparison. Thus font differences between platforms become less of an issue. You mean for example that the reference file of a css-border test that has some header-text describing the test would contain the same header-text but then a image to represent the reference of the css-part? It could be an image, or it could be a configuration ofdiv elements, or a table, or something else that can be configured to look exactly the same as the CSS border property being tested. Right. Seems to me we have all the pieces to the puzzle? DRT can ouput a PNG with --pixel-tests, we can add foo-reference.html to accompany foo-expected.txt, and run-webkit-tests can be taught to pick up on these reference-files and run DRT with pixel-tests on both and then use ImageDiff to compare them? Then we can gradually migrate tests to use references rather than expected render-trees? Tor Arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Disabling 'Reset Assignee to default' on component change on bugs.webkit.org
Hey, http://bugs.webkit.org/ currently has the behavior that if you change the component, the checkbox Reset Assignee to default is automatically checked, which will revert the assignee to the default for that component. The default for all our components is webkit-unassig...@webkit.org: https://bugs.webkit.org/describecomponents.cgi?product=WebKit Which means that if you change the component for a bug that has been assigned to someone, for example during triaging, you may accidentally remove that assignee and the bug may drop out of that person's filters, etc. I propose we remove this feature from our installation by doing something like: http://gist.github.com/306690 Thoughts? Tor Arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Disabling 'Reset Assignee to default' on component change on bugs.webkit.org
On 17/2/10 17:55 , Alexey Proskuryakov wrote: 17.02.2010, в 07:15, Tor Arne Vestbø написал(а): Which means that if you change the component for a bug that has been assigned to someone, for example during triaging, you may accidentally remove that assignee and the bug may drop out of that person's filters, etc. I propose we remove this feature from our installation by doing something like: One case this comes in handy is when moving a bug to Security, which has a different default assignee. Ah, in that case we can change it from assignToDefaultOnChange(['product', 'component']); to assignToDefaultOnChange(['product']); ? Tor Arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [Qt] Build problem due to newly introduced WebKit/qt/Api/DerivedSources.pro
On 2/5/10 4:51 PM, İsmail Dönmez wrote: Seems to be due to newly checked in DerivedSources.pro. Try applying this: http://gist.github.com/295937 I have to run but I'll land this on Monday. Tor Arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] changelogs: a reprise
Tor Arne Vestbø wrote: Here's a wip patch to update-webkit's Git part I've been running locally for a few days now, it has basic resolve-ChangeLogs-support, as well as mirror support: http://gist.github.com/287646 https://bugs.webkit.org/show_bug.cgi?id=34206 tor arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Tagging bug names with a platform name: limit to platform-specific patches
Darin Adler wrote: Hi folks. We’ve never formalized this, but I believe that patches tagged with a particular platform name such as [Qt] Add new API for fluffy bunnies should be limited to one particular platform’s code. If the patch changes more than a trivial bit of platform-independent code, even if the change is only for the benefit of a signle platform, I suggest we not use the platform name prefix. Agreed. Note also that we have keywords for both Qt and Gtk, so if a patch deals largely with platform-independent code, but has consequences for either of these ports, for example new API requirements or DRT hooks, please add the keyword to it pops up in filters. tor arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Did I break the build?
Eric Seidel wrote: http://build.webkit.org/console Will let you know. I love the console, thanks for adding this! tor arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Did I break the build?
Eric Seidel wrote: The Chromium developers, notably Nicolas Sylvain added /console. Mark Rowe is our kind BuildBot admin who updated our copy to the latest BuildBot version including this new feature. I was not involved. :) Then great thanks to both Nicolas and Mark!! :) tor arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch status display on bugs.webkit.org
Adam Barth wrote: As we bring more bots online, this user interface should scale better than posting lots of pass comments. If folks like this display, we can incorporate it into bugs.webkit.org directly. +1 for including this in the site directly! Cool stuff! Tor Arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Style guide for indenting nested #if #define in headers
Hey, Could not find anything in the style guide regarding indentation of nested #ifs/#ifdefs in headers, ie. not #ifdefs in normal code, where adding extra indentation would break the indentation of the surrounding code, but nested #ifdefs in files like Platform.h Personally I prefer indentation, for the same reason that we indent code (readability), but I just wanted to check if we have a guideline for this. Tor Arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Guided bug reporting on bugs.webkit.org
Hey, Right now we have the bug reporting guidelines, here: http://webkit.org/quality/bugwriting.html And the actual form here: https://bugs.webkit.org/enter_bug.cgi?product=WebKit Would it make sense to expand the create-form template in Bugzilla to join these two in a guided reporting, similar to e.g. Mozilla? https://bugzilla.mozilla.org/enter_bug.cgi?product=Coreformat=guided This would allow us to: - Provide the guidelines text inline with the fields, with examples etc... - Add mapping between released product versions of WebKit (Safari 4, Qt 4.5, WebKitGTk+ 1.1.15.1, Chrome 4.0.x, etc) to WebKit SVN revisions, so that the user chooses the product he observed the bug in, and we get the correct revision (and other fields filled out automatically). We could also auto-detect this using the UA. This info could go into a custom field, or as an automatic prefix to the details-comment. I guess the usefulness of something like this deepens on how we view the WebKit bugzilla. Is it for developers only? For users of WebKit API (C,ObjC,GTK,Qt). For advanced users of browsers/products that use WebKit (where the user knows the bug is a WebKit bug)? Anyways, I would be happy to work up a guided form template if the interest is there, but I wanted to poll the community first. Thoughts? :) Tor Arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [48407] trunk/LayoutTests
Chris Fleizach wrote: It's possible that Windows, for example, supports an accessibility value attribute for sliders, but it's also possible that it does not. Likewise, it's possible Linux could support that attribute, or not. All I am sure of right now is that it's not implemented now. So instead of adding Skipped tests for every platform except Mac on every checkin I make, I've just been making them mac tests only. If someone knows differently on these subjects, please let me know I'd say add Skipped tests for the other platforms. Let it be up to those platforms to decide if it can be implemented or not and when to remove it from the Skipped list. I might take a new platform version to do it, but at least the test is global for everyone, not hidden only for Mac. Tor Arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] User Stylesheets changes I'd like to make
On 9/4/09 9:47 PM, David Hyatt wrote: Right now the user stylesheet location is stored as a URL. This is based off ancient history, namely that we happened to store the preference this way on Mac. Even though Safari only allows you to pick local files from its UI for user stylesheets, the preference itself is a URL. Because of this, the current code is making an assumption that remote URLs should be allowed to work as user stylesheets. On Mac and Qt only, we have a UserStyleSheetLoader object that is dealing with remote URLs. Other platforms seem to just not support this. I would like to eliminate this object on all platforms. Sounds good. Tor Arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Building Webkit on Linux
On 8/11/09 12:30 PM, Jilu Oommen wrote: Hi, I am trying to build webkit on Linux using gcc (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8). Currently I am getting stuck on linking error: ar: DerivedSources/.libs/JSCSSCharsetRule.o: No such file or directory Can you please let me know a solution at the earliest. Or Please suggest the latest version of webkit source that will work fine on Linux. thanks in advance, Jil Please use webkit-h...@lists.webkit.org for these type of questions. Tor Arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Themes extending the style
Maciej Stachowiak wrote: Those of us involved in the discussion concluded that the best way to do this was to let RenderTheme subclasses add rules to the UA stylesheet, so that the core style rules can be in one place, but themes can adjust theme-specific style details that happen to be done with CSS rules. I just woke up, and haven't had my coffee yet, but didn't we add this in r268f45? The Qt port uses WebCore/platform/qt/html4-adjustments-qt.css to modify html4.css, not replace it as far as I remember. -- Tor Arne Vestbø, Software Engineer Qt Software, Nokia, Oslo, Norway http://www.trolltech.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Themes extending the style
Tor Arne Vestbø wrote: I just woke up, and haven't had my coffee yet, but didn't we add this in r268f45? Sorry, that was r34297 http://trac.webkit.org/changeset/34297 -- Tor Arne Vestbø, Software Engineer Qt Software, Nokia, Oslo, Norway http://www.trolltech.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit-r33371 compilation error against Qtopia Phone Edition 4.3.1
George wrote: I found this is occurred with Macro definition XP_UNIX, I clear it by commenting out the configuration in WebCore.pri: #qt-port:unix:!mac: DEFINES += XP_UNIX ENABLE_NETSCAPE_PLUGIN_API=1 Good catch, we should be doing qt-port:unix:!mac:!embedded. 2, when compiling HTMLFormElement.cpp ../../../WebCore/platform/FileSystem.h:138: error: 'PlatformModule' was not declared in this scope Add || defined(Q_WS_QWS) I'll sort this out in a patch. Thanks for reporting! Tor Arne -- Tor Arne Vestbø, Software Engineer Trolltech ASA, Oslo, Norway http://www.trolltech.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] How to abstract text drag delay and hysteresis
Hi, First of all, this is my first post to the webkit-dev list, so hi everyone! :) Now...we would like to provide values for text drag delay and hysteresis based on Qt defaults. What would be the preferred way of abstracting this? Adding #if PLATFORM(QT) in EventHandler.cpp does not sit quite right with me, but maybe a global function? Tor Arne -- Tor Arne Vestbø, Software Engineer Trolltech ASA, Oslo, Norway http://www.trolltech.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
