Re: [webkit-dev] Bugzilla Question - Master Bug vs Component?
On Jul 10, 2010, at 1:17 AM, Alex Milowski wrote: I would think we'd close it when we've actually completely implemented MathML. If this is what you want the bug to represent, then it does make sense to keep all feature-implementation bugs related to this master bug, but none of the bug bugs…if that makes any sense.The bug bugs should be in the MathML component, but they shouldn't block the feature-complete bug. Just enabling it seems like something we could do now but our implementation is quite impoverished with respect to MathML 3.0. I think we should consider enabling MathML. Just because we don't have MathML 3.0 implemented yet doesn't mean we need to keep it off; there was a time when we didn't have any CSS 3 implemented, but that didn't mean our CSS implementation had to be turned off! I have been playing around with a MathML-enabled build, and I feel like we do a pretty good job getting a lot of MathML on the web right, and I haven't experienced any crashes in the MathML code either. And if we turn it on, more people will test it, and that is just plain helpful. Just my opinion! -Beth ___ 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?
Le 12 juil. 2010 à 21:01, Beth Dakin a écrit : On Jul 10, 2010, at 1:17 AM, Alex Milowski wrote: I would think we'd close it when we've actually completely implemented MathML. If this is what you want the bug to represent, then it does make sense to keep all feature-implementation bugs related to this master bug, but none of the bug bugs…if that makes any sense.The bug bugs should be in the MathML component, but they shouldn't block the feature-complete bug. Just enabling it seems like something we could do now but our implementation is quite impoverished with respect to MathML 3.0. I think we should consider enabling MathML. Just because we don't have MathML 3.0 implemented yet doesn't mean we need to keep it off; there was a time when we didn't have any CSS 3 implemented, but that didn't mean our CSS implementation had to be turned off! I have been playing around with a MathML-enabled build, and I feel like we do a pretty good job getting a lot of MathML on the web right, and I haven't experienced any crashes in the MathML code either. And if we turn it on, more people will test it, and that is just plain helpful. Just my opinion! Opinion that I share! But I think that Alex was not meaning to wait until a full support of MathML 3. François Sausset ___ 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 12, 2010, at 11:01 AM, Beth Dakin wrote: On Jul 10, 2010, at 1:17 AM, Alex Milowski wrote: I would think we'd close it when we've actually completely implemented MathML. If this is what you want the bug to represent, then it does make sense to keep all feature-implementation bugs related to this master bug, but none of the bug bugs…if that makes any sense.The bug bugs should be in the MathML component, but they shouldn't block the feature-complete bug. Just enabling it seems like something we could do now but our implementation is quite impoverished with respect to MathML 3.0. I think we should consider enabling MathML. Just because we don't have MathML 3.0 implemented yet doesn't mean we need to keep it off; there was a time when we didn't have any CSS 3 implemented, but that didn't mean our CSS implementation had to be turned off! I have been playing around with a MathML-enabled build, and I feel like we do a pretty good job getting a lot of MathML on the web right, and I haven't experienced any crashes in the MathML code either. And if we turn it on, more people will test it, and that is just plain helpful. Just my opinion! I think it's fine to enable MathML soon, as long as we make sure of the following: 1) Using a MathML-enabled build shouldn't cause stability problems or functional or performance regressions when browsing ordinary non-MathML content. 2) We should try to do some fuzz testing to verify that MathML doesn't create security risks. #2 can happen after we enable MathML, but should probably happen before anyone ships it. Regards, Maciej ___ 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 Mon, Jul 12, 2010 at 7:49 PM, Maciej Stachowiak m...@apple.com wrote: I think it's fine to enable MathML soon, as long as we make sure of the following: 1) Using a MathML-enabled build shouldn't cause stability problems or functional or performance regressions when browsing ordinary non-MathML content. Some of tis is testable by passing all our test cases, right? Or did you have something else in mind? Do we have anything that measures performance for regressions? I suspect that the performance on MathML with complicated row structures isn't going to be good at the moment. There are two many multiple rendering passes for operator and content stretching and that can probably be optimized. On the other hand, it seems to do quite well on reasonable MathML. 2) We should try to do some fuzz testing to verify that MathML doesn't create security risks. #2 can happen after we enable MathML, but should probably happen before anyone ships it. What is involved in (2) ? I'm happy to try to beat on the code to make sure it works well enough for people to feel comfortable turning it on. -- --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] Bugzilla Question - Master Bug vs Component?
On Jul 12, 2010, at 4:06 PM, Alex Milowski wrote: On Mon, Jul 12, 2010 at 7:49 PM, Maciej Stachowiak m...@apple.com wrote: I think it's fine to enable MathML soon, as long as we make sure of the following: 1) Using a MathML-enabled build shouldn't cause stability problems or functional or performance regressions when browsing ordinary non-MathML content. Some of tis is testable by passing all our test cases, right? Or did you have something else in mind? That plus browsing around some, or using the Safari stress test feature, wuld be enough to show basic stability. Do we have anything that measures performance for regressions? The Safari team has some internal tests we could run, once you have a patch ready. I suspect that the performance on MathML with complicated row structures isn't going to be good at the moment. There are two many multiple rendering passes for operator and content stretching and that can probably be optimized. On the other hand, it seems to do quite well on reasonable MathML. At this point, what I'm concerned about is that turning MathML on doesn't regress performance of other things (such as page load speed of normal HTML pages, or memory use when not using MathML). I would not expect it to, but there's always the possibility of unexpected interactions. Optimizing MathML rendering itself is something that can be done after it gets turned on/ 2) We should try to do some fuzz testing to verify that MathML doesn't create security risks. #2 can happen after we enable MathML, but should probably happen before anyone ships it. What is involved in (2) ? I'm happy to try to beat on the code to make sure it works well enough for people to feel comfortable turning it on. I'm not an expert on making fuzzers, so maybe some of the security people here can chime in or perhaps even help out. Regards, Maciej ___ 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 Sat, Jul 10, 2010 at 2:19 AM, David Kilzer ddkil...@webkit.org wrote: IMO, it should be closed once MathML is enabled in the WebKit nightly builds and/or most ports. I would think we'd close it when we've actually completely implemented MathML. Just enabling it seems like something we could do now but our implementation is quite impoverished with respect to MathML 3.0. -- --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] Bugzilla Question - Master Bug vs Component?
On Sat, Jul 10, 2010 at 2:24 AM, Adam Barth aba...@webkit.org wrote: 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. That's something we're trying to get a handle on right now. Sausset François is going through the W3C test suite. One idea that occurred to me was to file bugs for each feature that block the master bug 3251. When all of those are complete and we can pass the W3C test suite, we can close 3251. -- --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] 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
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] 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
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
