[chromium-dev] Re: [HTML5] Please add HTML5 to your bugs
When I sync issues from WebKit they will get the label HTML5 if they have the keyword HTML5 in their Bugzilla database. However, I will add the label OWP so we can have simple searches on our side. Jon On Mon, Aug 17, 2009 at 1:20 PM, Andrew Scherkus scher...@chromium.orgwrote: That works for me as well. It would jive with Aaron's suggestion to remove versioning from HTML5: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-August/021854.html Andrew On Sat, Aug 15, 2009 at 4:00 PM, Darin Fisher da...@chromium.org wrote: Seems like a good thing, but to be nit picky, perhaps HTML5 is the wrong name for this? Maybe OWP would be better since HTML5 is only a subset of OWP?-Darin On Fri, Aug 14, 2009 at 4:19 PM, Andrew Scherkus scher...@chromium.orgwrote: Jon and I were going through the video bugs this morning and realized that there is no way to easily view all HTML5-related bugs. For example video is using label:Video, workers are using label:Workers, but (to pick on Jeremy) DOM Storage uses no extra label and owner:jor...@chromium.org owner%3ajor...@chromium.org might not be representative. Even if you don't want to use an extra label, Jon added a shiny new HTML5 label that we can mass-assign to all HTML-5 related issues making the query as easy as label:HTML5 Andrew --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: A note to the Chromium Authors
Whoops. You are using the Chrome ball when you should use the Chromium ball. The Chromium ball is shades of blue. The one you should use looks like this http://dev.chromium.org/_/rsrc/1220198801738/config/app/images/customLogo/customLogo.gif?revision=2 Jon On Mon, Jul 27, 2009 at 4:27 PM, RealWat varma...@gmail.com wrote: Please could you try again. We just bring it live today. :) Sorry for any inconvenient. Regards, Ti-Took Team On Jul 27, 11:52 am, PhistucK phist...@gmail.com wrote: I tried downloading it, but waited about ten seconds and the download will not start.Pass... ☆PhistucK On Mon, Jul 27, 2009 at 18:27, Titook varma...@gmail.com wrote: Dear Chromium Authors, We, at RealWat Inc., are proud to announce the beta release of the Ti- Took™ platform. Ti-Took is a safe web browsing software solution that integrates innovative technologies to deliver a fast, safe, easy and personalized web experience. Named after the tuk-tuk vehicles that carry riders anywhere all day long in east Asian cities and towns, Ti-Took is a simple, trustworthy way of navigating the complex and often dangerous world of the internet. We are happy to announce that Ti-Took™ Nuage web browser is based on Google Chromium open-source code. Ti-Took™ Nuage was originally designed using other web toolkit. However, after Google released the Chrome browser and source code, we immediately fall in love with its technology and design, and has since adopted it as our web browser framework. We prefer Google Chrome over alternative solutions for many other reasons, but mostly because it fills our requirements and direction where we see the web browser model moving forward. We hope we will collaborate to enrich both Google Chromium and Ti-Took Nuage. Best Regards, Ti-Took Authors Press Release: http://www.titook.org/blog/?p=523 Our sites: www.titook.net www.realwat.com On Twitter: http://twitter.com/ http://twitter.com/realwat http://twitter.com/DavineDC --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Proposal for adding ChangeLog files to Chromium
If you don't want to see this thread anymore you can use the 'm' shortcut to mute it. If you don't have a BUG in your commit comment then we probably won't even see your CL and it won't make the release notes. It would be enough, IMHO, to have the first line of your commit comment describe the change in a way that makes it clear that it should be highlighted in the release notes. A tag would be even better, but I understand all that extra typing can be tiresome. Anthony was not looking for a CHANGE_LOG like WebKit which included each CL. We already provide a link to all the CL commentshttp://build.chromium.org/buildbot/perf/dashboard/ui/changelog.html?url=/trunk/srcrange=20903:21176mode=htmlfor a release. He was looking for an entry to a file each time you have something release note worthy. My experience is that we have about 5 items that rise to this level with each release. If you don't want to do any of these things then you should subscribe to cr-rel-notify so you can see the proposed blog entry before it goes out. Then you can let us know when we have missed something interesting. Jon On Wed, Jul 22, 2009 at 11:47 AM, Scott Hess sh...@chromium.org wrote: BTW: if people aren't annotating their CL's with bugs, they SURELY won't annotate them with release notes or update the change log. Just aiming for the path of least resistance, here. -scott On Wed, Jul 22, 2009 at 11:46 AM, Scott Hesssh...@chromium.org wrote: The stuff I'm implementing is important to _me_, but is it important enough to be in the release notes? Maybe we should have a tag for the issue-tracker which indicates that the issue is release-note-worthy, and we could use action on those bugs to help figure out which items are worthy of being in the release notes? Then if someone complains that their change didn't make the release notes, we can tell them how to arrange for that in the future. From there, regular bug triage activities may suffice to work it down to a reasonable volume. -scott On Wed, Jul 22, 2009 at 11:33 AM, Anthony LaForgelafo...@google.com wrote: (Warning: TPM perspective) The main problem with the current system is that it's a very time consuming process to parse through ~1000 revisions each week. Even with filter tools which parse the SVN logs and look for revisions with closed bugs, specific keywords in the logs, specific files, auto-discarding reverts, etc... that still brings us down to about 150 entries that require manual review. Of those, a good portion are not immediately clear from either the bug title or the SVN summary as to exactly what the fix was for, which requires extra detective work. Once that's done we end up re-writing/ clarifying the text. Even with all that effort I'm not 100% satisfied that we're coming up with what I'd call good results (we hit most things, but it's easy to miss lots of important stuff). Given the labor intensiveness and the so so yield, it seems like this process is an excellent candidate for applying some distributed labor and automation. I understand the resistance to ChangeLogs, but it doesn't seem unreasonable to ask committers, who have the best sense of the nature of their work, to take an extra minute to put a single line descriptive comment along side their SVN commit (and for reviewers to check it). Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA External Phone: 1-650-214-4055 On Wed, Jul 22, 2009 at 10:09 AM, Peter Kasting pkast...@google.com wrote: On Wed, Jul 22, 2009 at 10:03 AM, Adam Langley a...@chromium.org wrote: On Wed, Jul 22, 2009 at 4:52 PM, Anthony LaForgelafo...@google.com wrote: Ok, I know when to stop pushing, that's reasonable and appreciated feedback. So shifting gears, it seems like everyone would be comfortable with using RELEASE_NOTES tag in SVN comments. Any thoughts from the group on best practices for using that the tag gets used effectively? Who said everyone was comfortable? I'm probably not going to bother writing RELEASE_NOTES pretty much ever. (In exchange, I frequently edit our release notes to be more complete or accurate.) If the goal is pointing people at something that lists all changes, we can do it with a script. If the goal is making the release notes for releases better, a ChangeLog wouldn't have helped you anyway. I'm not sure there is much advantage in modifications to the current system -- even if RELEASE_NOTES get written sometimes, you're still going to need to parse all the rest of the changes and decide what to say. * When reverting, the log is reverted as well: Actually, I've never been too sure about reverting in WebKit: does one revert the ChangeLog file too or add another ChangeLog entry at the top describing the revert? Unless my memory is faulty, according to the Apple folks who have guided me
[chromium-dev] 3.0.195.1 Released to Dev Channel
See http://googlechromereleases.blogspot.com/ for more information. Jon --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Fwd: Fixing the ... in Issue Tracker
Thank you for asking this. This privacy feature is a real pain for me. Unfortunately, I can't turn it off by default for team members. I wish I could. I am dependent on everyone to discover the checkbox in the privacy section of http://code.google.com/hosting/settings and turn it off. Jon On Thu, Jul 16, 2009 at 3:49 PM, Fabien Tassin f...@sofaraway.org wrote: Hi, by any chance, do you know if it's possible to change how my name is shown in code.google.com? I appear as 'f...@sofaraway.org', i would prefer just 'fta' as in my profile. Some other users seem to be able to do that, i can't figure out how. Thanks. /Fabien --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Processing Nominations on Thursdays
I am batching up the requests for provisional and full committer access and processing them on Thursdays. If people are speedy about getting back to me as I ask them to create their accounts then I can usually complete them all within the day. If there is a real emergency I'll certainly make an exception. Jon --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Milestone Label Changes
If you don't care about milestone labels you can stop reading now. You may have noticed the flurry of emails around changing labels. We have removed the mstone-2.1 label and replaced it with mstone-3. You will also notice that the version file on trunk is now 3.x. As we settle into a regular cycle of releases the program managers have decided to use a simple numbering scheme for releases. It could be that we need a release like 2.1.x.y but we won't assume that. Instead we will work on the assumption that we will have release 2 followed by 3. This means that if you are working on a new feature for the June code freeze you are working on milestone 3. If you are working on something that will not ship until the next milestone then you are working on milestone 4. Anything not assigned to a milestone is milestone-X. I have updated the official labels to reflect this approach. Jon --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Dev Channel Release cut at 15751
The Dev Channel release 2.0.180.0 has been cut at CL 15751. See http://src.chromium.org/viewvc/chrome/branches/180/ for all of the CLs from DEPS. Jon --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] MStone changes
After a conversation in the multi-platform meeting today it was decided to deprecate the mstone:mac and mstone:linux labels in issue tracker in favor of mstone:MacDev and mstone:MacBeta and the corresponding Linux labels. This will allow the team to differentiate between issues required for the dev channel release and the beta channel release. Both teams should triage the lists. I am happy to help with this. Jon --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] 2.0.177.1 Released to Dev Channel
Google Chrome 2.0.177.1 has been released to the Dev channel. It includes a number of fixes and a couple UI tweaks. For example, if you have searched from wikipedia.org in the past, start typing wikipedia.org in the omnibox, press the Tab key then a search term and suggestions and past searches will appear for Wikipedia. Other fixes include: - [r14196 http://src.chromium.org/viewvc/chrome?view=revrevision=14196] Scrollbars, Home/End work again in Gmail (Issue: 10009http://code.google.com/p/chromium/issues/detail?id=10009 ) - [r14377 http://src.chromium.org/viewvc/chrome?view=revrevision=14377] Flash (and other plugins) can be installed without restarting the browser. (Issue: 10574 http://code.google.com/p/chromium/issues/detail?id=10574) - [r14137 http://src.chromium.org/viewvc/chrome?view=revrevision=14137] Fix hang seen in plugin process, including the new O3D plugin. (Issue: 10711 http://code.google.com/p/chromium/issues/detail?id=10711) - [r13934 http://src.chromium.org/viewvc/chrome?view=revrevision=13934 ] On some sites text disappears or is never drawn. For example, on Google Calendar, the titles for all day events do not display. (Issue: 9904http://code.google.com/p/chromium/issues/detail?id=9904 ) Detailed release noteshttp://sites.google.com/a/chromium.org/dev/getting-involved/dev-channel/release-notes/releasenotes201771 are available. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] 2.0.176.0 for Dev Channel cut at r14196
I have the CL I needed so I am going to cut the new dev channel release from the trunk at r14196. This brings in the fix for scrolling in GMail. Jon --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Area-DevTools Deprecated
Given that we have developer tools like the debugger that are intended for web developers there is some confusion over the Area-DevTools label. We have replaced that with Area-Infrastructure. This area is for things related to the internal systems like buildbots, tests, etc. There is a new label for external developer tools. It is not an Area. The proper Area for the debugger and other tools for web developers is Area-WebKit. The new label is... DevTools. Jon --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] MStone:Mac MStone:Linux
It helps to bucket Issues into milestones. So far we have had numbered milestones like 2 and 2.1. However, I think it makes sense to have a MStone:Mac and an MStone:Linux as well. I am moving Mac and Linux issues into these. Basically if an issue it in these buckets we would expect it to be resolved before we release to the general public. If the Issue should go out in a specific stable release like 2.0 or 2.1 then we should move them into that mstone. Also, MStone:X is the someday in the future bucket. If I put stuff in there (especially feature requests) that means I did not just reject them outright and they should be considered fodder for discussion. Jon --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] 2.0.169.1 released to the dev channel
We just pushed the Omaha config changes for 2.0.169.1 to become the new dev channel release. Thank you to everyone for your hard work! Jon --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Stabilization Effort Daily Report
*Report for 2009-2-2* *Layout Tests* Our progress over the last few days has been flat. We need to get below that 300 bug line. [image: All+Tests=78.0][image: Want+To+Pass=95.4] http://spreadsheets.google.com/ccc?key=pMwul3Seofg4uTdanKb9iWw [image: History of passing tests %]http://spreadsheets.google.com/ccc?key=pMwul3Seofg4uTdanKb9iWwBe sure to sign up at http://spreadsheets.google.com/ccc?key=pMwul3Seofg448Q1VFJjsJAhl=en if you are going to work on a layout test. We don't want to step on each other's toes. All Tests is based on all available layout tests including those that we are currently not trying to pass. There are tests in this group which are known to be bad or relate to future technologies. Want to Pass is based on the tests that we need to be passing before we will ship a revision of the browser. Getting this number as high as possible is the goal of the stabilization effort. Some of these tests are failing due to subtle changes that require the test to be re-baselined. Crashers We have 9 remaining crashers. *Purify Bugs (Memory)* We have 19 remaining Purify issues. *Regressions* We 7 remaining regressions, although that number is likely to go up. *Other bugs* We have 38 other bugs to resolve. So our bug burndown chart looks like this: I reset the blue line after a bunch of Purify bugs from UI tests landed all at once. As long as we keep the red line below the blue line we are on track for the bugs. Keep in mind that this does not include the work on Layout Tests. You will find a lot more information about the Stabilization effort on the Wiki at http://code.google.com/p/chromium/wiki/StabilizeTrunk --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Stabilization Effort Daily Report
*Report for 2009-1-28* Recent merges have taken a bit of a toll on our layout test passing rate. For the last few days we have been more or less flat on our progress. We are still on pace but we are losing that buffer that we will certainly need as we get into the harder bugs. In the last few days we have made significant progress on the Issues with label:stable, as you can see by the graph at the bottom of this email. I really appreciate everyone who has contributed fixes recently. I have been trying very hard to review each of the open issues to throw out issues that do not apply and to ask for reductions or repro steps on everything. I hope when you pull up a bug to work on it that you have the information you need. If you don't -- email me. If you are frustrated with http://crash you may want to try Dremel with Crash. Anthony sent out an email about this a little while ago. It provides you with a SQL-ish interface to Crash. If you have a useful query I would appreciate it if you would share it with the class. :) *Layout Tests* Our progress over the last few days has been flat. We need to get below that 300 bug line. I am working on making the spreadsheet better. Hopefully I will get those changes in today. [image: All+Tests=78.1][image: Want+To+Pass=95.6] http://spreadsheets.google.com/ccc?key=pMwul3Seofg4uTdanKb9iWw [image: History of passing tests %]http://spreadsheets.google.com/ccc?key=pMwul3Seofg4uTdanKb9iWw Be sure to sign up at http://spreadsheets.google.com/ccc?key=pMwul3Seofg448Q1VFJjsJAhl=en if you are going to work on a layout test. We don't want to step on each other's toes. All Tests is based on all available layout tests including those that we are currently not trying to pass. There are tests in this group which are known to be bad or relate to future technologies. Want to Pass is based on the tests that we need to be passing before we will ship a revision of the browser. Getting this number as high as possible is the goal of the stabilization effort. Some of these tests are failing due to subtle changes that require the test to be re-baselined. Crashers Of the 26 crashers we have assigned to stable we have resolved 18! *Purify Bugs (Memory)* We have resolved 35 of the 77 Purify issues. *Regressions* We have resolved 21 of 26 regressions. The bad news here is that there appear to be some regressions that are missing the stable label and not showing up in the query. I will be looking for those over the next couple days. *Other bugs* We have also resolved 22 of the 53 other bugs. So our bug burndown chart looks like this: I reset the blue line after a bunch of Purify bugs from UI tests landed all at once. As long as we keep the red line below the blue line we are on track for the bugs. Keep in mind that this does not include the work on Layout Tests. You will find a lot more information about the Stabilization effort on the Wiki at http://code.google.com/p/chromium/wiki/StabilizeTrunk --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Fwd: Stabilization Effort Daily Report
*Report for 2009-1-22* While our layout test progress looks great I am increasingly worried about crashers. We held back the 2.0.158.0 dev release because it is crashing too much. Having regular dev channel releases is very important to me because I think it helps us find problems early. I will try to get the crashers list fixed up so they represent the big offenders so we can make the most progress with the least effort. If you are frustrated with http://crash you may want to try Dremel with Crash. Anthony sent out an email about this a little while ago. It provides you with a SQL-ish interface to Crash. If you have a useful query I would appreciate it if you would share it with the class. :) *Layout Tests* We are closing on average 10 layout tests a day. We need a pace of at least 9 a day to stay on target for the end of the quarter so we are gaining ground. It is likely that the pace will get harder to maintain as we go along so it is great that we have gained some headroom! [image: All+Tests=78.2][image: Want+To+Pass=95.7] http://spreadsheets.google.com/ccc?key=pMwul3Seofg4uTdanKb9iWw [image: History of passing tests %]http://spreadsheets.google.com/ccc?key=pMwul3Seofg4uTdanKb9iWw Be sure to sign up at http://spreadsheets.google.com/ccc?key=pMwul3Seofg448Q1VFJjsJAhl=en if you are going to work on a layout test. We don't want to step on each other's toes. All Tests is based on all available layout tests including those that we are currently not trying to pass. There are tests in this group which are known to be bad or relate to future technologies. Want to Pass is based on the tests that we need to be passing before we will ship a revision of the browser. Getting this number as high as possible is the goal of the stabilization effort. Some of these tests are failing due to subtle changes that require the test to be re-baselined. Crashers Of the 27 crashers we have assigned to stable we have resolved 8. *Purify Bugs (Memory)* We have resolved 28 of the 78 Purify issues. That is the same as Wednesday. *Regressions* We have resolved 17 of 28 regressions. That is the same as Wednesday. *Other bugs* We have also resolved 21 of the 53 other bugs. That is the same as Wednesday. So our bug burndown chart looks like this: I reset the blue line after a bunch of Purify bugs from UI tests landed all at once. As long as we keep the red line below the blue line we are on track for the bugs. Keep in mind that this does not include the work on Layout Tests. You will find a lot more information about the Stabilization effort on the Wiki at http://code.google.com/p/chromium/wiki/StabilizeTrunk --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Stabilization Effort Daily Report
I reviewed all of the crashers that we have open. I was able to remove one and resolve a couple as duplicates or Won't Fix because they do not repro on the trunk. So... out of 26 we have resolved 12 (1 is upstream). All of the open issues have and owner. I appreciate everyone's help! Jon On Fri, Jan 23, 2009 at 12:40 PM, Jon j...@chromium.org wrote: *Report for 2009-1-22* While our layout test progress looks great I am increasingly worried about crashers. We held back the 2.0.158.0 dev release because it is crashing too much. Having regular dev channel releases is very important to me because I think it helps us find problems early. I will try to get the crashers list fixed up so they represent the big offenders so we can make the most progress with the least effort. If you are frustrated with http://crash you may want to try Dremel with Crash. Anthony sent out an email about this a little while ago. It provides you with a SQL-ish interface to Crash. If you have a useful query I would appreciate it if you would share it with the class. :) *Layout Tests* We are closing on average 10 layout tests a day. We need a pace of at least 9 a day to stay on target for the end of the quarter so we are gaining ground. It is likely that the pace will get harder to maintain as we go along so it is great that we have gained some headroom! [image: All+Tests=78.2][image: Want+To+Pass=95.7] http://spreadsheets.google.com/ccc?key=pMwul3Seofg4uTdanKb9iWw [image: History of passing tests %]http://spreadsheets.google.com/ccc?key=pMwul3Seofg4uTdanKb9iWw Be sure to sign up at http://spreadsheets.google.com/ccc?key=pMwul3Seofg448Q1VFJjsJAhl=en if you are going to work on a layout test. We don't want to step on each other's toes. All Tests is based on all available layout tests including those that we are currently not trying to pass. There are tests in this group which are known to be bad or relate to future technologies. Want to Pass is based on the tests that we need to be passing before we will ship a revision of the browser. Getting this number as high as possible is the goal of the stabilization effort. Some of these tests are failing due to subtle changes that require the test to be re-baselined. Crashers Of the 27 crashers we have assigned to stable we have resolved 8. *Purify Bugs (Memory)* We have resolved 28 of the 78 Purify issues. That is the same as Wednesday. *Regressions* We have resolved 17 of 28 regressions. That is the same as Wednesday. *Other bugs* We have also resolved 21 of the 53 other bugs. That is the same as Wednesday. So our bug burndown chart looks like this: I reset the blue line after a bunch of Purify bugs from UI tests landed all at once. As long as we keep the red line below the blue line we are on track for the bugs. Keep in mind that this does not include the work on Layout Tests. You will find a lot more information about the Stabilization effort on the Wiki at http://code.google.com/p/chromium/wiki/StabilizeTrunk --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Stabilization Effort Daily Report
*Report for 2009-1-20* On Tuesday we we resolved 31 layout tests! This is really great progress. At the same time we continue to be up with the tip of tree from WebKit so the merges are landing regularly without causing us too much heartbreak. At this point, even at the rate of 9 a day, we could finish the first week of March which would be amazing! The Stability burndown chart got reset when a batch of un-reported Purify bugs dropped in today. To get those under control our bug squashing needs to be at the rate of 6 a day for the next four weeks. Many of these Purify issues should be straightforward so I hope we can make up some ground quickly. I reset the blue line to reflect the required pace. *Layout Tests* We now pass more tests than we have ever passed. With our All Tests percentage nearing 80% we are doing better than ever before! [image: All+Tests=77.8][image: Want+To+Pass=95.4] http://spreadsheets.google.com/ccc?key=pMwul3Seofg4uTdanKb9iWw [image: History of passing tests %]http://spreadsheets.google.com/ccc?key=pMwul3Seofg4uTdanKb9iWw Be sure to sign up at http://spreadsheets.google.com/ccc?key=pMwul3Seofg448Q1VFJjsJAhl=en if you are going to work on a layout test. We don't want to step on each other's toes. All Tests is based on all available layout tests including those that we are currently not trying to pass. There are tests in this group which are known to be bad or relate to future technologies. Want to Pass is based on the tests that we need to be passing before we will ship a revision of the browser. Getting this number as high as possible is the goal of the stabilization effort. Some of these tests are failing due to subtle changes that require the test to be re-baselined. Crashers Of the 24 crashers we have assigned to stable we have resolved 7. We have been at the same place for a couple days. We will need to make progress here. A recent editorial on CNehttp://news.cnet.com/8301-17939_109-10144520-2.html?tag=mncol t mentions leaving Chrome for Firefox because dev channel releases are too unreliable. *Purify Bugs (Memory)* We have resolved 28 of the 78 Purify issues. That is eight more than last Friday. *Regressions* We have resolved 17 of 28 regressions. *Other bugs* We have also resolved 21 of the 52 other bugs. So our bug burndown chart looks like this: I reset the blue line after a bunch of Purify bugs from UI tests landed all at once. As long as we keep the red line below the blue line we are on track for the bugs. Keep in mind that this does not include the work on Layout Tests. You will find a lot more information about the Stabilization effort on the Wiki at http://code.google.com/p/chromium/wiki/StabilizeTrunk --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Stabilization Effort Daily Report
*Report for 2009-1-16* We continue to make great progress on layout tests and we are ahead of pace to finish by the end of the quarter. Of course most of these early wins are low-hanging fruit so we will eat into that lead as we move along but I have to say that I love the look of this chart! The Stability burndown chart got reset when a batch of un-reported Purify bugs dropped in today. To get those under control our bug squashing needs to be at the rate of 6 a day for the next four weeks. Many of these Purify issues should be straightforward so I hope we can make up some ground quickly. I reset the blue line to reflect the required pace. I still need an owner for this bug: Issue 5541 http://code.google.com/p/chromium/issues/detail?id=5541: REGRESSION: bad drop-shadow rendering *Layout Tests* Since Monday we have resolved over 100 layout test failures! That is more than twice the pace we need to stay on target. We also passed the 95% park for tests we Want to Pass! Fantastic! [image: All+Tests=77.5][image: Want+To+Pass=95.1] http://spreadsheets.google.com/ccc?key=pMwul3Seofg4uTdanKb9iWw [image: History of passing tests %]http://spreadsheets.google.com/ccc?key=pMwul3Seofg4uTdanKb9iWw Be sure to sign up at http://spreadsheets.google.com/ccc?key=pMwul3Seofg448Q1VFJjsJAhl=en if you are going to work on a layout test. We don't want to step on each other's toes. All Tests is based on all available layout tests including those that we are currently not trying to pass. There are tests in this group which are known to be bad or relate to future technologies. Want to Pass is based on the tests that we need to be passing before we will ship a revision of the browser. Getting this number as high as possible is the goal of the stabilization effort. Some of these tests are failing due to subtle changes that require the test to be re-baselined. Crashers Of the 24 crashers we have assigned to stable we have resolved 7. That is two more than yesterday. We have been adding crashers to this list but I have also been trying to weed out any that I can. *Purify Bugs (Memory)* We have resolved 20 of the 72 Purify issues. There was a big batch of Purify bugs that had not been entered into the bug tracker so if you look at the chart you will see an explosion of issues. Therefore I have reset the blue line to take these into account. There may be another 15 coming. *Regressions* We have resolved 18 of 28 regressions. We resolved one additional regression since yesterday. *Other bugs* We have also resolved 21 of the 49 other bugs. So our bug burndown chart looks like this: We have popped above the blue line but we are making great progress on layout tests. As long as we keep the red line below the blue line we are on track for the bugs. Keep in mind that this does not include the work on Layout Tests. You will find a lot more information about the Stabilization effort on the Wiki at http://code.google.com/p/chromium/wiki/StabilizeTrunk --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] What is up with the test PreservedWindowPlacementIsLoaded?
While triaging the new Purify bugs I noticed that one test was showing up in a lot of cases. Here is the list: http://code.google.com/p/chromium/issues/list?can=2q=label:stable+label:purify+PreservedWindowPlacementIsLoaded It would be great if these fourteen failures were all somehow related. Several of the purify errors only occur in this one test. Jon --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Stabilization Effort Daily Report
*Report for 2009-1-12* We are on pace to fix the layout tests by the end of the quarter. I really appreciate everyone who is already contributing to this effort. If you have not yet experienced the distinct joy of fixing a layout test we happen to have some more sitting around for you! Anyone who is already listed on http://go/layout-bugs will be happy to answer questions. Yesterday I asked Tony and Eric to pose for the video camera. We recorded their Crash Course in Fixing Layout Tests. Now I need to edit it. Once I am done we will post it to YouTube and encourage external engineers to try their hand. The more the merrier! I still need an owner for this bug: Issue 5541 http://code.google.com/p/chromium/issues/detail?id=5541: REGRESSION: bad drop-shadow rendering *Layout Tests* We had a net gain of 10 passing unit tests yesterday! We need to fix at least 9 so every additional fix is great! [image: All+Tests=76.3][image: Want+To+Pass=93.9] http://spreadsheets.google.com/ccc?key=pMwul3Seofg4uTdanKb9iWw [image: History of passing tests %]http://spreadsheets.google.com/ccc?key=pMwul3Seofg4uTdanKb9iWw Be sure to sign up at http://spreadsheets.google.com/ccc?key=pMwul3Seofg448Q1VFJjsJAhl=en if you are going to work on a layout test. We don't want to step on each other's toes. All Tests is based on all available layout tests including those that we are currently not trying to pass. There are tests in this group which are known to be bad or relate to future technologies. Want to Pass is based on the tests that we need to be passing before we will ship a revision of the browser. Getting this number as high as possible is the goal of the stabilization effort. Some of these tests are failing due to subtle changes that require the test to be re-baselined. *Purify Bugs (Memory)* We have resolved 26 of the 42 Purify issues. We resolved 3 additional Purify bugs since the last email. *Regressions* We have resolved 15 of 25 regressions. We resolved two additional regressions. *Other bugs* We have also resolved 20 of the 46 other bugs. We resolved two more. So our bug burndown chart looks like this: As long as we keep the red line below the blue line we are on track for the bugs. Keep in mind that this does not include the work on Layout Tests. You will find a lot more information about the Stabilization effort on the Wiki at http://code.google.com/p/chromium/wiki/StabilizeTrunk --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Problems compiling with xcode 3.1
You probably used svn directly instead of gclient. http://dev.chromium.org/developers/how-tos/get-the-code I think you can recover by going into your repository directory (not into src) and using: gclient config http://src.chromium.org/svn/trunk/src Then use: gclient sync Then always use gclient sync instead of svn sync. Jon On Mon, Jan 12, 2009 at 9:19 AM, kc kec...@gmail.com wrote: Hi, I am kind of new to this. Could someone pls kindly help provide me with some guidance? I ran into tons and tons of compilation errors with xcode 3.1. (I downloaded the tarball base and did a sync while tree is opened). The first error I ran into said it couldnt find the header file carbon/carbon.h in an include of one of the cc files. What I noticed is that Carbon/Carbon.h (Upper Case) will rid of that particular error. Lot of errors look like it doesnt know how to handle header files. I speculate one can fix this in the Build Settings (under Project Edit Project Settings). I went there and under the Build tab, I am wondering why it only contained user defined settings, and missing all the others (eg. Compiler Version, Search Paths). Thanks. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Stabilization Effort Daily Report
*Report for 2009-1-8* As Eric pointed out, the progress we made was negated by new failures introduced by the most recent WebKit merge. This will likely continue to be a problem. If you have not yet resolved a layout test bug it would be good to take a break from the other bugs and tackle one. We are doing well on Purify and the other bugs but need to gain some ground on layout tests. A couple days focusing on layout tests would be really helpful I added a new chart to http://go/stable that shows the burndown for layout tests. It assumes we have until the end of the quarter. The rate of fixes needs to be about 9 a day if we are to hit our goal. If you are not fixing at least one a day then we are probably falling behind. It is a lot of work -- there just is no escaping the need to get these things fixed and the longer it takes us the more likely we are to be even further behind by the end of the quarter. I still need owners for these two bugs, please take one of these: Issue 5541 http://code.google.com/p/chromium/issues/detail?id=5541: REGRESSION: bad drop-shadow rendering Issue 5559 http://code.google.com/p/chromium/issues/detail?id=5559: REGRESSION: cannot select text in gmail compose using shift+click if scroll between clicks *Layout Tests* We had a net gain of 2 passing unit tests yesterday. We need to gain 9 each day to be on pace to complete by the end of March. Be sure to sign up at http://spreadsheets.google.com/ccc?key=pMwul3Seofg448Q1VFJjsJAhl=en if you are going to work on a layout test. We don't want to step on each other's toes. [image: All+Tests=76.5][image: Want+To+Pass=92.5] http://spreadsheets.google.com/ccc?key=pMwul3Seofg4uTdanKb9iWw [image: History of passing tests %]http://spreadsheets.google.com/ccc?key=pMwul3Seofg4uTdanKb9iWw All Tests is based on all available layout tests including those that we are currently not trying to pass. There are tests in this group which are known to be bad or relate to future technologies. Want to Pass is based on the tests that we need to be passing before we will ship a revision of the browser. Getting this number as high as possible is the goal of the stabilization effort. Some of these tests are failing due to subtle changes that require the test to be re-baselined. *Purify Bugs (Memory)* We have resolved 23 of the 42 Purify issues. We did not resolve a new Purify bug yesterday. *Regressions* We have resolved 13 of 25 regressions. We resolved one additional regression yesterday. *Other bugs* We have also resolved 18 of the 42 other bugs. We resolved one more since yesterday. So our bug burndown chart looks like this: As long as we keep the red line below the blue line we are on track for the bugs. Keep in mind that this does not include the work on Layout Tests. You will find a lot more information about the Stabilization effort on the Wiki at http://code.google.com/p/chromium/wiki/StabilizeTrunk --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Stabilization Effort Daily Report
*Report for 2009-1-7* We need to make progress on the layout tests. Everyone should have their name next to at least one Layout Test. I still need owners for these two bugs, please take one of these: Issue 5541 http://code.google.com/p/chromium/issues/detail?id=5541: REGRESSION: bad drop-shadow rendering Issue 5559 http://code.google.com/p/chromium/issues/detail?id=5559: REGRESSION: cannot select text in gmail compose using shift+click if scroll between clicks *Layout Tests* No change since yesterday and the big jump was due to Ojan reclassifying a bunch of tests. We need to make progress. Layout tests are the bulk of the work and a day without progress is a big problem. Be sure to sign up at http://spreadsheets.google.com/ccc?key=pMwul3Seofg448Q1VFJjsJAhl=en if you are going to work on a layout test. We don't want to step on each other's toes. [image: All+Tests=76.5][image: Want+To+Pass=92.5] http://spreadsheets.google.com/ccc?key=pMwul3Seofg4uTdanKb9iWw [image: History of passing tests %]http://spreadsheets.google.com/ccc?key=pMwul3Seofg4uTdanKb9iWw All Tests is based on all available layout tests including those that we are currently not trying to pass. There are tests in this group which are known to be bad or relate to future technologies. Want to Pass is based on the tests that we need to be passing before we will ship a revision of the browser. Getting this number as high as possible is the goal of the stabilization effort. Some of these tests are failing due to subtle changes that require the test to be re-baselined. *Purify Bugs (Memory)* We have resolved 23 of the 42 Purify issues. That is four more than yesterday. *Regressions* We have resolved 12 of 25 regressions. No progress yesterday. *Other bugs* We have also resolved 17 of the 42 other bugs. Only one more since yesterday. So our bug burndown chart looks like this: As long as we keep the red line below the blue line we are on track for the bugs. Keep in mind that this does not include the work on Layout Tests. You will find a lot more information about the Stabilization effort on the Wiki at http://code.google.com/p/chromium/wiki/StabilizeTrunk --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Stabilization Effort Daily Report
I am going to find a way to post Eric's stuff. It would be great to have a world visible web server that we can use to publish these internal reports. So far I have been using a script to update the SVN repository of the wiki on code.google.com which is not very satisfying. Jon On Tue, Jan 6, 2009 at 8:59 AM, Evan Martin e...@chromium.org wrote: On Mon, Jan 5, 2009 at 10:49 PM, Jon j...@chromium.org wrote: The Layout Tests class went well. We are going to record it next week so people can watch it on demand. Eric's slides are at http://www.corp.google.com/~ericroman/layout/ I appreciate the enthusiasm! This isn't world-readable. Perhaps we should set up webspace on chromium.org for hosting these sorts of things? Dimitri's webkit merge tracker page would also be useful. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: HTTP BASIC/DIGEST BUG - Has it been fixed yet?
The builds from the trunk, which include this fix, will be coming soon to the dev channel. You can immediately try the latest builds at http://build.chromium.org/buildbot/continuous/LATEST/ although these builds are bleeding edge. Information about joining the dev channel is at http://dev.chromium.org/getting-involved/dev-channel/ Watch for news about the dev and beta channels this week on our official blog at http://blog.chromium.org/ Jon On Mon, Jan 5, 2009 at 1:05 PM, Wan-Teh Chang w...@google.com wrote: On Mon, Jan 5, 2009 at 12:28 PM, Evan Martin e...@chromium.org wrote: It would help if you link to the bug in the bug tracker. I believe this message is in reference to http://code.google.com/p/chromium/issues/detail?id=1629 which has been marked fixed. This bug has been fixed on the trunk of the Chromium source tree. But the fix isn't in the latest Google Chrome release yet because it is based on a branch created in November. We didn't backport the bug fix to the official branch because it's a big patch so there's a risk that we may introduce other bugs when we adapt it for the official branch, which uses a completely different HTTP stack. Hopefully the fix will appear in a Dev Channel release as part of our new HTTP stack very soon. Note: the bug is not that Chromium doesn't support HTTP BASIC and DIGEST authentication. The bug is that Chromium will only send a HTTP Authorization header after receiving a 401 Authorization Required response to the first attempt of the request. Wan-Teh Chang --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Stabilization Effort Daily Report
*Report for 2009-1-5* The Layout Tests class went well. We are going to record it next week so people can watch it on demand. Eric's slides are at http://www.corp.google.com/~ericroman/layout/http://www.corp.google.com/%7Eericroman/layout/ I appreciate the enthusiasm! It is a good idea to look at http://code.google.com/p/chromium/wiki/StabilizeTrunk for the latest information. The Wiki also includes information on how to help fix layout tests. This is a great way to get involved and begin to learn the codebase. If you have ever wanted to be an open source developer then this is a great way to start! *Layout Tests* Each day the report at http://www.corp.google.com/~jonc/layout-summary.htmlhttp://www.corp.google.com/%7Ejonc/layout-summary.html will be updated with recent results. This report allows you to find layout tests that are failing on all platforms. It also makes it clear which directories have the most failures if you would like to work in a specific area. As always be sure to sign up at http://spreadsheets.google.com/ccc?key=pMwul3Seofg448Q1VFJjsJAhl=en if you are going to work on a layout test. We don't want to step on each other's toes. Our hopes that the *jultomte http://en.wikipedia.org/wiki/Tomte * would fix all the layout tests did not pan out so we are going to have to do it ourselves. Here is where we currently stand: [image: To+Be+Fixed=1.4][image: All+Tests=74.9][image: Want+To+Pass=90.4] The Fixed percentage is based on the layout tests in the tests_fixablehttp://src.chromium.org/viewvc/chrome/trunk/src/webkit/tools/layout_tests/test_lists/tests_fixable.txt?view=markup file. These are tests we are currently ignoring because we know they fail. As soon as we fix them we move them out of fixable so this number does not tend to get very high. It can momentarily spike between the time we fix the test and update the file. All tests is based on all available layout tests including those that we are currently not trying to pass. There are tests in this group which are known to be bad or relate to future technologies. Want to Pass is based on the tests that we need to be passing before we will ship a revision of the browser. Getting this number as high as possible is the goal of the stabilization effort. Some of these tests are failing due to subtle changes that require the test to be re-baselined. *Purify Bugs (Memory)* We have resolved 10 of the 40 Purify issues. That is two more than before the holiday break. *Regressions* We have resolved 11 of 25 regressions. That is one more since before the holiday break. *Other bugs* We have also resolved 12 of the 43 other bugs. That is 2 more than before the break but there are also 2 new ones. So our bug burndown chart looks like this: As long as we keep the red line below the blue line we are on track for the bugs. Keep in mind that this does not include the work on Layout Tests. You will find a lot more information about the Stabilization effort on the Wiki at http://code.google.com/p/chromium/wiki/StabilizeTrunk --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Stabilization Effort Daily Report
*Report for 2009-12-22* Over the holiday this report won't be very daily but you get the picture. *Layout Tests* We have not made much improvement on the layout tests so far. The 90 day trend shows that we have recovered from the webkit merges but we still have a long way to go. When everyone is back from the holidays we will be having a crash-course on layout tests. I hope to get this video-taped so we can share it broadly. [image: To+Be+Fixed=1.4][image: All+Tests=74.8][image: Want+To+Pass=90.2] [image: History of passing tests %]http://spreadsheets.google.com/ccc?key=pMwul3Seofg4uTdanKb9iWw The Fixed percentage is based on the layout tests in the tests_fixablehttp://src.chromium.org/viewvc/chrome/trunk/src/webkit/tools/layout_tests/test_lists/tests_fixable.txt?view=markup file. These are tests we are currently ignoring because we know they fail. As soon as we fix them we move them out of fixable so this number does not tend to get very high. It can momentarily spike between the time we fix the test and update the file. All tests is based on all available layout tests including those that we are currently not trying to pass. There are tests in this group which are known to be bad or relate to future technologies. Want to Pass is based on the tests that we need to be passing before we will ship a revision of the browser. Getting this number as high as possible is the goal of the stabilization effort. Some of these tests are failing due to subtle changes that require the test to be re-baselined. This report is available at http://www/~jonc/webkit.htmlhttp://www/%7Ejonc/webkit.html for Googlers. I am trying to find a good way to make it available externally. Links to the same report for Mac and Linux is available as well from the Wikihttp://code.google.com/p/chromium/wiki/StabilizeTrunk?ts=1229629370updated=StabilizeTrunk . *Purify Bugs (Memory)* We have resolved 8 of the 40 Purify issues. That is good progress. Thank you to everyone who is working on those issueshttp://code.google.com/p/chromium/issues/list?can=1q=label:stable%20purifysort=statuscolspec=ID%20Stars%20Pri%20Area%20Type%20Status%20Summary%20Modified%20Owner. *Regressions* We have resolved 8 of 25 regressions and upstreamed one of them to WebKit. This is also good progress. *Other bugs* We have also resolved 8 of the 41 other bugs. So our bug burndown chart looks like this: [image: pub.png] As long as we keep the red line below the blue line we are on track for the bugs. Keep in mind that this does not include the work on Layout Tests. You will find a lot more information about the Stabilization effort on the Wiki at http://code.google.com/p/chromium/wiki/StabilizeTrunk?ts=1229629370updated=StabilizeTrunk --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~--- inline: pub.png
