[webkit-dev] Bugzilla Question - Master Bug vs Component?
For MathML we have a master bug 3251 that we've been making depend on every new patch for MathML. That is a very nice in that as new patches are added and committed, you can get notifications of the changes in status. We also have the MathML component that all bugs should be associated with. As time goes but, bugs should get filed against the MathML component but they won't be associated with the master bug for MathML. What is the preferred process here? Should we keep the master bug? Should we use it only for our implementation efforts and not make it depend on every random bug filed for the MathML component? I certainly have my opinion on this. I'd rather not associated everything that gets reported with the master bug. Instead, I'd rather we only associated our implementation efforts or issues describing sub-features related to implementation of certain features of MathML (e.g. glyph inspection to tighten under/over placement). We can then make the bugs filed by random users depend on such implementation efforts associated with the master bug. I expect to get a lot of bugs like my MathML is messed up, here's an example where the specifics of why will be associated with a number of different specific technical issues. Basically, my preference is: master bug - feature or technical issue - user bug -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Commit Queue Love
Independently of the other long thread, I'd like to express my love of the commit queue. It is actually quite a nice feature for someone like myself who is off in a corner. I don't want commit access. I'd rather my changes go through some process like the commit queue to ensure that it doesn't break other people's code or block forward development in some way. It is very frustrating sometimes when your patch is stuck in the commit queue for days. I don't necessarily see that as being caused by the commit queue. That is directly because it isn't getting the love it deserves! :) Being able to go around the commit queue means you can cheat. That seems like something that should be reserved for more severe problems where we know the process used by the commit queue will fail. If committers need some kind of specialized access, maybe they just need a fast track commit queue, a higher priority, or some additional options, so that the policies for building and testing can be uniformly applied while still meeting their needs. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DerivedSources.make CPP DOM Bindings
On Jul 8, 2010, at 11:04 AM, Kevin Ollivier kev...@theolliviers.com wrote: I'm working on making the CPP DOM bindings accessible to the wx port, and while I've got the whole thing building, one thing I have yet to sort out is how to add building of the CPP DOM bindings to the build system. DerivedSources.make seems to be the appropriate place to put the code, and it's where I've put things for now, but I wasn't sure if others would feel this is the right place. DerivedSources.make is the appropriate place for this. If I do add it, what is the appropriate way to do it? Should generation be conditional on some define the port will set, like MAKE_CPP_BINDINGS, or should we just directly check for BUILDING_PORT defines? I would use BUILDING_PORT for now until such time as another port wants to enable it. Dave -- Sent from my iPhone 3GS ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bugzilla Question - Master Bug vs Component?
On Jul 9, 2010, at 6:23 AM, Alex Milowski wrote: For MathML we have a master bug 3251 that we've been making depend on every new patch for MathML. That is a very nice in that as new patches are added and committed, you can get notifications of the changes in status. If all you're concerned about is getting email notifications, we can add you to the default CC list for the MathML component. We also have the MathML component that all bugs should be associated with. As time goes but, bugs should get filed against the MathML component but they won't be associated with the master bug for MathML. What is the preferred process here? Should we keep the master bug? Should we use it only for our implementation efforts and not make it depend on every random bug filed for the MathML component? I think an important question to ask is, When will you move the master bug to Resolved/Fixed? This is basically another way of saying, What task(s) does the master bug represent? Once you know that answer, the answers to your other questions may be obvious. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Commit Queue Love
On Jul 9, 2010, at 3:38 AM, Alex Milowski wrote: Being able to go around the commit queue means you can cheat. That seems like something that should be reserved for more severe problems where we know the process used by the commit queue will fail. That is not how I see it at all. And calling it cheating is quite offensive to me. Just because I want control over when and how my patch is committed is suddenly considered cheating? Some of the glaring reasons I don't use the commit queue have been resolved (svn blame mainly), but the fact that there is no control over when the path lands is my chief reason. Often I need to update Apple's internal bug database when I make a change to WebKit, so I just can't rely on the commit bot to close the bugzilla bug. That means holding a bug open and knowing go back days later when it finally lands to close the internal bug. Other times there are internal deadlines that need to be meet and hours matter. As well as keeping patches that span WebKit and Safari in-sync. So until the commit queue solves these issues, I will keep exercising my right to svn commit and be responsive to problems my commits might bring. But please lets stop calling it cheating. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Commit Queue Love
On Fri, Jul 9, 2010 at 3:39 PM, Timothy Hatcher timo...@apple.com wrote: On Jul 9, 2010, at 3:38 AM, Alex Milowski wrote: Being able to go around the commit queue means you can cheat. That seems like something that should be reserved for more severe problems where we know the process used by the commit queue will fail. That is not how I see it at all. And calling it cheating is quite offensive to me. Just because I want control over when and how my patch is committed is suddenly considered cheating? Sorry, that wasn't meant to be offensive. It is going around a process. That said, not everyone has committed to using that process. So, you're right. It isn't cheating. All I'm advocating is using the commit queue much more often. I don't have any control over when my code hits the trunk. Somehow, it all works out in the end. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Commit Queue Love
On Fri, Jul 9, 2010 at 7:39 AM, Timothy Hatcher timo...@apple.com wrote: Some of the glaring reasons I don't use the commit queue have been resolved (svn blame mainly), but the fact that there is no control over when the path lands is my chief reason. I agree. When my patch has a potential to affect the other parts of WebKit, I have to watch waterfall and commit myself to see all builders pass all the tests so that I can FIX them as needed. I didn't take Alex's post offensive though. Best, Ryosuke Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] STIX Fonts and MathML Tests
I filled a bug and submitted a patch with fonts and license only: https://bugs.webkit.org/show_bug.cgi?id=41961 Does anyone could tell if this license is compatible with the WebKit one? François Sausset Le 7 juil. 2010 à 21:25, Dan Bernstein a écrit : On Jul 7, 2010, at 11:17 AM, Sausset François wrote: If every is OK with licenses, how DumpRenderTree needs to be modified to use custom fonts? This is where the Mac version activates test fonts: http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/mac/DumpRenderTree.mm#L218 and this is where the Windows version does it: http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/win/DumpRenderTree.cpp#L275 You will also need to modify the build system to copy the additional fonts to the right places. And where the fonts have to be stored? Most are here: http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/fonts Ahem is currently in http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/qt/fonts but had better be moved to the cross-platform location. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bugzilla Question - Master Bug vs Component?
On Jul 9, 2010, at 7:34 AM, Adam Roben wrote: I think an important question to ask is, When will you move the master bug to Resolved/Fixed? This is basically another way of saying, What task(s) does the master bug represent? Once you know that answer, the answers to your other questions may be obvious. I think this is great feedback. Personally, I think the master bug should represent only bugs that would prevent MathML from being turned on in the build by default. It would also be a very valuable exercise to consider what those bugs might be. -Beth ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Snow Leopard Bot went down
/Volumes/Data/WebKit-BuildSlave/snowleopard-intel-release/build/WebCore/config.h:212: fatal error: error writing to -: Broken pipe compilation terminated. i686-apple-darwin10-gcc-4.2.1: Internal error: Segmentation fault (program as) Please submit a full bug report. See URL:http://developer.apple.com/bugreporter for instructions. http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20(Build)/builds/13344/steps/compile-webkit/logs/stdio Any theories? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Snow Leopard Bot went down
No theories. But another data point; Tiger started doing the same a few revisions earlier: /Volumes/Data/WebKit-BuildSlave/tiger-intel-release/build/WebKit/mac/WebView/WebView.mm: In function 'void -[WebView(WebPrivate) _commonInitializationWithFrameName:groupName:usesDocumentViews:](WebView*, objc_selector*, NSString*, NSString*, BOOL)': /Volumes/Data/WebKit-BuildSlave/tiger-intel-release/build/WebKit/mac/WebView/WebView.mm:628: internal compiler error: Segmentation fault On Fri, Jul 9, 2010 at 3:13 PM, Eric Seidel e...@webkit.org wrote: /Volumes/Data/WebKit-BuildSlave/snowleopard-intel-release/build/WebCore/config.h:212: fatal error: error writing to -: Broken pipe compilation terminated. i686-apple-darwin10-gcc-4.2.1: Internal error: Segmentation fault (program as) Please submit a full bug report. See URL:http://developer.apple.com/bugreporter for instructions. http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20(Build)/builds/13344/steps/compile-webkit/logs/stdio Any theories? ___ 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] webkit-patch, check-webkit-style and git now support --squash and --git-commit
This has landed. Squashing is now the default behavior. --git-commit/-g operates on the commit(s) listed as a single commit. --git-commit=HEAD.. operates on the working copy. Ojan On Mon, May 24, 2010 at 5:10 PM, Ojan Vafai o...@chromium.org wrote: I posted a patch to https://bugs.webkit.org/show_bug.cgi?id=39624. Which prompted further discussion on #webkit. We came to a different conclusion. The basic idea is that webkit-patch should work right without any flags for some workflow. We can make it work right for the branch-per-bug workflow and write a separate wrapper script to make the commit-per-bug workflow work. Specifically the behavior would be the following: - Squashing should be the default behavior. In cases where squashing might do something unexpected (e.g. commit multiple local changes), we'll prompt the user to see if they want to continue. The prompt can be avoided by adding webkit-patch.squash to the git config. There won't be any --squash or --no-squash commands. - --git-commit will work as outlined below except that * will no longer mean squash. Unless I hear objections, I'll change my patch for bug 39624 to implement the above. Ojan On Mon, May 17, 2010 at 2:21 PM, Ojan Vafai o...@chromium.org wrote: On Sun, May 16, 2010 at 10:38 AM, Chris Jerdonek cjerdo...@webkit.orgwrote: On Sun, May 16, 2010 at 8:26 AM, Ojan Vafai o...@chromium.org wrote: On Sat, May 15, 2010 at 2:17 PM, Chris Jerdonek cjerdo...@webkit.org wrote: In particular, --git-commit=HEAD.. should be just the uncommitted changes (staged and unstaged). This one I'm a bit iffy on. Should this include the commit at head? I think it should. Currently, when using check-webkit-style for example, I need to pass --git-commit=HEAD^.. to include the commit at head. In other words, it operates on ranges like the above exclusively with respect to the endpoint. This is similar to how git-diff behaves and is described here: http://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html Were you thinking about changing this behavior? Someone also pointed out off thread that including working copy changes doesn't match any existing git commands. I think we should try to stay as close to git semantics as possible. So, I'm revising the proposal. It weirds me out the --git-commit=head~3..head~2 and --git-commit=head~2 do the same thing, but it turns out most git commands work that way. I propose: default: operate on working copy changes. Errors if there are no working copy changes or if there are committed changes. Gives a nice error message saying what to do. --git-commit=* operate on all changes in your branch as a single commit, including working copy changes --git-commit=head~2 operate on head~2 --git-commit=head~2.. operate on head~2, head~1 and head --git-commit=head~4..head~2 operate on head~3 and head~2 as a single commit Sound good? Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bugzilla Question - Master Bug vs Component?
On Jul 9, 2010, at 7:34 AM, Adam Roben aro...@apple.com wrote: On Jul 9, 2010, at 6:23 AM, Alex Milowski wrote: Should we keep the master bug? Should we use it only for our implementation efforts and not make it depend on every random bug filed for the MathML component? I think an important question to ask is, When will you move the master bug to Resolved/Fixed? This is basically another way of saying, What task(s) does the master bug represent? Once you know that answer, the answers to your other questions may be obvious. IMO, it should be closed once MathML is enabled in the WebKit nightly builds and/or most ports. Dave -- Sent from my iPhone 3GS ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bugzilla Question - Master Bug vs Component?
On Fri, Jul 9, 2010 at 6:19 PM, David Kilzer ddkil...@webkit.org wrote: On Jul 9, 2010, at 7:34 AM, Adam Roben aro...@apple.com wrote: On Jul 9, 2010, at 6:23 AM, Alex Milowski wrote: Should we keep the master bug? Should we use it only for our implementation efforts and not make it depend on every random bug filed for the MathML component? I think an important question to ask is, When will you move the master bug to Resolved/Fixed? This is basically another way of saying, What task(s) does the master bug represent? Once you know that answer, the answers to your other questions may be obvious. IMO, it should be closed once MathML is enabled in the WebKit nightly builds and/or most ports. Out of curiosity, is there an estimate of when that might be? There's some interaction with the new HTML5 parser because it supports MathML-in-HTML. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
