[chromium-dev] Telling svn to ignore VS's .user files
Just a heads up for others who find it annoying when svn st always shows the vcproj.GOOGLE.username.user files. You can put *.user in the global-ignores setting in svn's config file to avoid this. --~--~-~--~~~---~--~~ 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: 2-day merges and the cleanup schedule
Added layout-test cleanup steps to the instructions. - Pam On Wed, Mar 4, 2009 at 6:08 PM, David Levin wrote: > I know that I haven't filed chromium bugs for layout test failures in the > past because it isn't in the instructions (I thought adding the the > tests_fixable was sufficient.) > > http://dev.chromium.org/developers/how-tos/webkit-merge-1 > > > Though I do usually have at least a partial 3rd day of items for clean up: > upstreaming, some times filing bugs for new reliability crashes, etc. > Dave > > > On Wed, Mar 4, 2009 at 5:30 PM, Pam Greene wrote: > >> I'm not sure how closely that's followed. Me, I did merges Monday and >> Tuesday, and layout-test cleanup (baselines and bugs) today. >> - Pam >> >> >> On Wed, Mar 4, 2009 at 5:10 PM, Darin Fisher wrote: >> >>> Right. I just mean that the merger should take care to ensure that all >>> of the easy "fixes" are done and that the rest are accounted for somehow, >>> probably via regression bugs. If that's the current process, then great. >>> It just sounded like it wasn't. >>> -Darin >>> >>> >>> >>> On Wed, Mar 4, 2009 at 4:51 PM, Pam Greene wrote: >>> Define "resolved". Is filing and assigning a bug sufficient? It's not efficient to have whoever volunteers to do a merge personally pester people to fix the resulting test errors forever after. Whatever we do, we're going to have broken layout tests after a merge. Easy "fixes" -- re-baselining the ones that are actually all right, and filing specific bugs for the rest -- are definitely part of the merge task. But we don't want to put too much blame on the messenger: if a bunch of tests really break, or new tests don't pass, it's hardly the fault of the person who happened to bring the changes in. - Pam On Wed, Mar 4, 2009 at 3:18 PM, Darin Fisher wrote: > I think the merger should be responsible for ensuring that any layout > test fallout from the merge gets resolved. This doesn't mean necessary > fixing everything, but rather it can be mean reaching out to others for > help. > I think the merger has to have incentive not to create a big mess with > the merge and to also make sure the job gets done completely :-) > > -Darin > > > On Wed, Mar 4, 2009 at 10:06 AM, Scott Violet wrote: > >> >> If we are ever to keep up to date with layout tests we need to come to >> a consensus on this. Here's the current set of proposals: >> >> 1. The merge becomes a two day activity. First day is merge, second >> day is fixing any failing layout tests. >> 2. We tag team people: first person does merge, next day another >> person fixes any failing layout tests. >> 3. One person for merge (like we do now), and failures are handled by >> owners of the layout tests. This assumes we can identify owners for >> buckets of layout tests so that folks know they are on the spot for a >> failing test. >> >> At this point we only care about regressions since 1.0, but that'll >> change soon. >> >> Can we make a decision on this at next weeks WebKit meeting? >> >> -Scott >> >> On Thu, Jan 15, 2009 at 1:03 PM, Brett Wilson >> wrote: >> > >> > I'm currently doing a 2-day merge rotation.As part of this, various >> > layout tests are regressing or getting added that I'm inserting into >> > the tests_fixable list. >> > >> > But, like every other layout test fixer, after my merges are done, >> > I'll finally go back to my old work and not think about it any more. >> > This is how we get a monotonically increasing list of broken tests >> at >> > the end of the tests fixable. I'm pretty certain this happens faster >> > than the tests are getting fixed because nobody wants to fix them. >> I'm >> > sort of tempted to just fix the ones my merge broke now, but that >> will >> > put me behind for my next merge, so I don't do that. >> > >> > I propose a different rotation schedule for WebKit merges. You would >> > do one day of merges, and the next day you would have to clean up >> all >> > the regressed and new layout tests your merge introduced. The layout >> > tests usually aren't that hard, so it normally wouldn't take the >> whole >> > day. This way we can be in a good steady state of WebKit merges. It >> > should also have a big advantage for fixing the broken tests since >> the >> > things that changed, the build numbers involved, etc. are still >> fresh >> > in the merger's head, and it won't be like approaching a random >> layout >> > test from the list with no context. >> > >> > The disadvantage of doing this is that we have to find people to do >> > the merges faster (we should probably formalize the schedule), and >> > you'll lose some advantage the second day of having all the >> > i
[chromium-dev] Re: 2-day merges and the cleanup schedule
I know that I haven't filed chromium bugs for layout test failures in the past because it isn't in the instructions (I thought adding the the tests_fixable was sufficient.) http://dev.chromium.org/developers/how-tos/webkit-merge-1 Though I do usually have at least a partial 3rd day of items for clean up: upstreaming, some times filing bugs for new reliability crashes, etc. Dave On Wed, Mar 4, 2009 at 5:30 PM, Pam Greene wrote: > I'm not sure how closely that's followed. Me, I did merges Monday and > Tuesday, and layout-test cleanup (baselines and bugs) today. > - Pam > > > On Wed, Mar 4, 2009 at 5:10 PM, Darin Fisher wrote: > >> Right. I just mean that the merger should take care to ensure that all of >> the easy "fixes" are done and that the rest are accounted for somehow, >> probably via regression bugs. If that's the current process, then great. >> It just sounded like it wasn't. >> -Darin >> >> >> >> On Wed, Mar 4, 2009 at 4:51 PM, Pam Greene wrote: >> >>> Define "resolved". Is filing and assigning a bug sufficient? It's not >>> efficient to have whoever volunteers to do a merge personally pester people >>> to fix the resulting test errors forever after. >>> Whatever we do, we're going to have broken layout tests after a merge. >>> Easy "fixes" -- re-baselining the ones that are actually all right, and >>> filing specific bugs for the rest -- are definitely part of the merge task. >>> But we don't want to put too much blame on the messenger: if a bunch of >>> tests really break, or new tests don't pass, it's hardly the fault of the >>> person who happened to bring the changes in. >>> >>> - Pam >>> >>> On Wed, Mar 4, 2009 at 3:18 PM, Darin Fisher wrote: >>> I think the merger should be responsible for ensuring that any layout test fallout from the merge gets resolved. This doesn't mean necessary fixing everything, but rather it can be mean reaching out to others for help. I think the merger has to have incentive not to create a big mess with the merge and to also make sure the job gets done completely :-) -Darin On Wed, Mar 4, 2009 at 10:06 AM, Scott Violet wrote: > > If we are ever to keep up to date with layout tests we need to come to > a consensus on this. Here's the current set of proposals: > > 1. The merge becomes a two day activity. First day is merge, second > day is fixing any failing layout tests. > 2. We tag team people: first person does merge, next day another > person fixes any failing layout tests. > 3. One person for merge (like we do now), and failures are handled by > owners of the layout tests. This assumes we can identify owners for > buckets of layout tests so that folks know they are on the spot for a > failing test. > > At this point we only care about regressions since 1.0, but that'll > change soon. > > Can we make a decision on this at next weeks WebKit meeting? > > -Scott > > On Thu, Jan 15, 2009 at 1:03 PM, Brett Wilson > wrote: > > > > I'm currently doing a 2-day merge rotation.As part of this, various > > layout tests are regressing or getting added that I'm inserting into > > the tests_fixable list. > > > > But, like every other layout test fixer, after my merges are done, > > I'll finally go back to my old work and not think about it any more. > > This is how we get a monotonically increasing list of broken tests at > > the end of the tests fixable. I'm pretty certain this happens faster > > than the tests are getting fixed because nobody wants to fix them. > I'm > > sort of tempted to just fix the ones my merge broke now, but that > will > > put me behind for my next merge, so I don't do that. > > > > I propose a different rotation schedule for WebKit merges. You would > > do one day of merges, and the next day you would have to clean up all > > the regressed and new layout tests your merge introduced. The layout > > tests usually aren't that hard, so it normally wouldn't take the > whole > > day. This way we can be in a good steady state of WebKit merges. It > > should also have a big advantage for fixing the broken tests since > the > > things that changed, the build numbers involved, etc. are still fresh > > in the merger's head, and it won't be like approaching a random > layout > > test from the list with no context. > > > > The disadvantage of doing this is that we have to find people to do > > the merges faster (we should probably formalize the schedule), and > > you'll lose some advantage the second day of having all the > > instructions and gotchas of the merge fresh in your mind. I was > > thinking of a 3 day schedule (2 days of merging, 1 day of fixing) but > > that seems too heavyweight for the people volunteering to do this. > > > > Anybody have any com
[chromium-dev] Re: 2-day merges and the cleanup schedule
I'm not sure how closely that's followed. Me, I did merges Monday and Tuesday, and layout-test cleanup (baselines and bugs) today. - Pam On Wed, Mar 4, 2009 at 5:10 PM, Darin Fisher wrote: > Right. I just mean that the merger should take care to ensure that all of > the easy "fixes" are done and that the rest are accounted for somehow, > probably via regression bugs. If that's the current process, then great. > It just sounded like it wasn't. > -Darin > > > > On Wed, Mar 4, 2009 at 4:51 PM, Pam Greene wrote: > >> Define "resolved". Is filing and assigning a bug sufficient? It's not >> efficient to have whoever volunteers to do a merge personally pester people >> to fix the resulting test errors forever after. >> Whatever we do, we're going to have broken layout tests after a merge. >> Easy "fixes" -- re-baselining the ones that are actually all right, and >> filing specific bugs for the rest -- are definitely part of the merge task. >> But we don't want to put too much blame on the messenger: if a bunch of >> tests really break, or new tests don't pass, it's hardly the fault of the >> person who happened to bring the changes in. >> >> - Pam >> >> On Wed, Mar 4, 2009 at 3:18 PM, Darin Fisher wrote: >> >>> I think the merger should be responsible for ensuring that any layout >>> test fallout from the merge gets resolved. This doesn't mean necessary >>> fixing everything, but rather it can be mean reaching out to others for >>> help. >>> I think the merger has to have incentive not to create a big mess with >>> the merge and to also make sure the job gets done completely :-) >>> >>> -Darin >>> >>> >>> On Wed, Mar 4, 2009 at 10:06 AM, Scott Violet wrote: >>> If we are ever to keep up to date with layout tests we need to come to a consensus on this. Here's the current set of proposals: 1. The merge becomes a two day activity. First day is merge, second day is fixing any failing layout tests. 2. We tag team people: first person does merge, next day another person fixes any failing layout tests. 3. One person for merge (like we do now), and failures are handled by owners of the layout tests. This assumes we can identify owners for buckets of layout tests so that folks know they are on the spot for a failing test. At this point we only care about regressions since 1.0, but that'll change soon. Can we make a decision on this at next weeks WebKit meeting? -Scott On Thu, Jan 15, 2009 at 1:03 PM, Brett Wilson wrote: > > I'm currently doing a 2-day merge rotation.As part of this, various > layout tests are regressing or getting added that I'm inserting into > the tests_fixable list. > > But, like every other layout test fixer, after my merges are done, > I'll finally go back to my old work and not think about it any more. > This is how we get a monotonically increasing list of broken tests at > the end of the tests fixable. I'm pretty certain this happens faster > than the tests are getting fixed because nobody wants to fix them. I'm > sort of tempted to just fix the ones my merge broke now, but that will > put me behind for my next merge, so I don't do that. > > I propose a different rotation schedule for WebKit merges. You would > do one day of merges, and the next day you would have to clean up all > the regressed and new layout tests your merge introduced. The layout > tests usually aren't that hard, so it normally wouldn't take the whole > day. This way we can be in a good steady state of WebKit merges. It > should also have a big advantage for fixing the broken tests since the > things that changed, the build numbers involved, etc. are still fresh > in the merger's head, and it won't be like approaching a random layout > test from the list with no context. > > The disadvantage of doing this is that we have to find people to do > the merges faster (we should probably formalize the schedule), and > you'll lose some advantage the second day of having all the > instructions and gotchas of the merge fresh in your mind. I was > thinking of a 3 day schedule (2 days of merging, 1 day of fixing) but > that seems too heavyweight for the people volunteering to do this. > > Anybody have any comments? > Brett > > > > >>> >>> >>> >>> >> > --~--~-~--~~~---~--~~ 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: 2-day merges and the cleanup schedule
I'm ok with saying that you do the merge one day and have another day to cleanup layout test issues. Once we're not merging anymore though, I think we should just have 1-2 people oncall for 1 week at a time to keep the webkit(webkit.org) build green and to pull a new revision at least once a day (this latter part we can automate pretty easily as well). Ojan On Wed, Mar 4, 2009 at 5:10 PM, Darin Fisher wrote: > Right. I just mean that the merger should take care to ensure that all of > the easy "fixes" are done and that the rest are accounted for somehow, > probably via regression bugs. If that's the current process, then great. > It just sounded like it wasn't. > -Darin > > > > On Wed, Mar 4, 2009 at 4:51 PM, Pam Greene wrote: > >> Define "resolved". Is filing and assigning a bug sufficient? It's not >> efficient to have whoever volunteers to do a merge personally pester people >> to fix the resulting test errors forever after. >> Whatever we do, we're going to have broken layout tests after a merge. >> Easy "fixes" -- re-baselining the ones that are actually all right, and >> filing specific bugs for the rest -- are definitely part of the merge task. >> But we don't want to put too much blame on the messenger: if a bunch of >> tests really break, or new tests don't pass, it's hardly the fault of the >> person who happened to bring the changes in. >> >> - Pam >> >> On Wed, Mar 4, 2009 at 3:18 PM, Darin Fisher wrote: >> >>> I think the merger should be responsible for ensuring that any layout >>> test fallout from the merge gets resolved. This doesn't mean necessary >>> fixing everything, but rather it can be mean reaching out to others for >>> help. >>> I think the merger has to have incentive not to create a big mess with >>> the merge and to also make sure the job gets done completely :-) >>> >>> -Darin >>> >>> >>> On Wed, Mar 4, 2009 at 10:06 AM, Scott Violet wrote: >>> If we are ever to keep up to date with layout tests we need to come to a consensus on this. Here's the current set of proposals: 1. The merge becomes a two day activity. First day is merge, second day is fixing any failing layout tests. 2. We tag team people: first person does merge, next day another person fixes any failing layout tests. 3. One person for merge (like we do now), and failures are handled by owners of the layout tests. This assumes we can identify owners for buckets of layout tests so that folks know they are on the spot for a failing test. At this point we only care about regressions since 1.0, but that'll change soon. Can we make a decision on this at next weeks WebKit meeting? -Scott On Thu, Jan 15, 2009 at 1:03 PM, Brett Wilson wrote: > > I'm currently doing a 2-day merge rotation.As part of this, various > layout tests are regressing or getting added that I'm inserting into > the tests_fixable list. > > But, like every other layout test fixer, after my merges are done, > I'll finally go back to my old work and not think about it any more. > This is how we get a monotonically increasing list of broken tests at > the end of the tests fixable. I'm pretty certain this happens faster > than the tests are getting fixed because nobody wants to fix them. I'm > sort of tempted to just fix the ones my merge broke now, but that will > put me behind for my next merge, so I don't do that. > > I propose a different rotation schedule for WebKit merges. You would > do one day of merges, and the next day you would have to clean up all > the regressed and new layout tests your merge introduced. The layout > tests usually aren't that hard, so it normally wouldn't take the whole > day. This way we can be in a good steady state of WebKit merges. It > should also have a big advantage for fixing the broken tests since the > things that changed, the build numbers involved, etc. are still fresh > in the merger's head, and it won't be like approaching a random layout > test from the list with no context. > > The disadvantage of doing this is that we have to find people to do > the merges faster (we should probably formalize the schedule), and > you'll lose some advantage the second day of having all the > instructions and gotchas of the merge fresh in your mind. I was > thinking of a 3 day schedule (2 days of merging, 1 day of fixing) but > that seems too heavyweight for the people volunteering to do this. > > Anybody have any comments? > Brett > > > > >>> >>> >>> >> > > > > --~--~-~--~~~---~--~~ 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: 2-day merges and the cleanup schedule
Right. I just mean that the merger should take care to ensure that all of the easy "fixes" are done and that the rest are accounted for somehow, probably via regression bugs. If that's the current process, then great. It just sounded like it wasn't. -Darin On Wed, Mar 4, 2009 at 4:51 PM, Pam Greene wrote: > Define "resolved". Is filing and assigning a bug sufficient? It's not > efficient to have whoever volunteers to do a merge personally pester people > to fix the resulting test errors forever after. > Whatever we do, we're going to have broken layout tests after a merge. Easy > "fixes" -- re-baselining the ones that are actually all right, and filing > specific bugs for the rest -- are definitely part of the merge task. But we > don't want to put too much blame on the messenger: if a bunch of tests > really break, or new tests don't pass, it's hardly the fault of the person > who happened to bring the changes in. > > - Pam > > On Wed, Mar 4, 2009 at 3:18 PM, Darin Fisher wrote: > >> I think the merger should be responsible for ensuring that any layout test >> fallout from the merge gets resolved. This doesn't mean necessary fixing >> everything, but rather it can be mean reaching out to others for help. >> I think the merger has to have incentive not to create a big mess with the >> merge and to also make sure the job gets done completely :-) >> >> -Darin >> >> >> On Wed, Mar 4, 2009 at 10:06 AM, Scott Violet wrote: >> >>> >>> If we are ever to keep up to date with layout tests we need to come to >>> a consensus on this. Here's the current set of proposals: >>> >>> 1. The merge becomes a two day activity. First day is merge, second >>> day is fixing any failing layout tests. >>> 2. We tag team people: first person does merge, next day another >>> person fixes any failing layout tests. >>> 3. One person for merge (like we do now), and failures are handled by >>> owners of the layout tests. This assumes we can identify owners for >>> buckets of layout tests so that folks know they are on the spot for a >>> failing test. >>> >>> At this point we only care about regressions since 1.0, but that'll >>> change soon. >>> >>> Can we make a decision on this at next weeks WebKit meeting? >>> >>> -Scott >>> >>> On Thu, Jan 15, 2009 at 1:03 PM, Brett Wilson >>> wrote: >>> > >>> > I'm currently doing a 2-day merge rotation.As part of this, various >>> > layout tests are regressing or getting added that I'm inserting into >>> > the tests_fixable list. >>> > >>> > But, like every other layout test fixer, after my merges are done, >>> > I'll finally go back to my old work and not think about it any more. >>> > This is how we get a monotonically increasing list of broken tests at >>> > the end of the tests fixable. I'm pretty certain this happens faster >>> > than the tests are getting fixed because nobody wants to fix them. I'm >>> > sort of tempted to just fix the ones my merge broke now, but that will >>> > put me behind for my next merge, so I don't do that. >>> > >>> > I propose a different rotation schedule for WebKit merges. You would >>> > do one day of merges, and the next day you would have to clean up all >>> > the regressed and new layout tests your merge introduced. The layout >>> > tests usually aren't that hard, so it normally wouldn't take the whole >>> > day. This way we can be in a good steady state of WebKit merges. It >>> > should also have a big advantage for fixing the broken tests since the >>> > things that changed, the build numbers involved, etc. are still fresh >>> > in the merger's head, and it won't be like approaching a random layout >>> > test from the list with no context. >>> > >>> > The disadvantage of doing this is that we have to find people to do >>> > the merges faster (we should probably formalize the schedule), and >>> > you'll lose some advantage the second day of having all the >>> > instructions and gotchas of the merge fresh in your mind. I was >>> > thinking of a 3 day schedule (2 days of merging, 1 day of fixing) but >>> > that seems too heavyweight for the people volunteering to do this. >>> > >>> > Anybody have any comments? >>> > Brett >>> > >>> > > >>> > >>> >>> >>> >> >> >> >> > --~--~-~--~~~---~--~~ 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: 2-day merges and the cleanup schedule
Right. Ultimately, we need to have a buildbot visible on build.webkit.orgthat reports layout test failures to others in the webkit community. Then, we can pester the webkit contributor to help fix the problems they caused. At the very least, we'll have the big advantage of knowing precisely which change caused a problem. This applies not only to layout tests, but also to performance regressions and stability (reliability test runs will be triggered by WebKit commits!). -Darin On Wed, Mar 4, 2009 at 5:05 PM, Ojan Vafai wrote: > The process I was picturing is that we'd have a WebKit sheriff. That person > would be in charge of keeping the build with latest webkit green and > updating the webkit revision we pull once a day. If someone else needs a > newer webkit revision (e.g. something they just committed), they can work > with the WebKit sherriff to pull it in. But basically, it would be that > person's job to either rebaseline failing tests or add them to the fixable > list and assign them to someone to fix. > Ojan > > > On Wed, Mar 4, 2009 at 5:01 PM, David Levin wrote: > >> Yes, so what would be the process then? (Will we still have "mergers" >> whose job is mostly to handle new and modified layout tests?) >> >> On Wed, Mar 4, 2009 at 4:58 PM, Ojan Vafai wrote: >> >>> Even once pulling in a new webkit is as simple as changing a revision >>> number in DEPS, we'll still have new and modified layout tests that we'll >>> need to deal with. >>> >>> >>> On Wed, Mar 4, 2009 at 4:44 PM, David Levin wrote: >>> Aren't we trying to get rid of the merge process (soon-ish)? If so, how would layout tests get fixed at that point? Dave On Wed, Mar 4, 2009 at 3:18 PM, Darin Fisher wrote: > I think the merger should be responsible for ensuring that any layout > test fallout from the merge gets resolved. This doesn't mean necessary > fixing everything, but rather it can be mean reaching out to others for > help. > I think the merger has to have incentive not to create a big mess with > the merge and to also make sure the job gets done completely :-) > > -Darin > > > On Wed, Mar 4, 2009 at 10:06 AM, Scott Violet wrote: > >> >> If we are ever to keep up to date with layout tests we need to come to >> a consensus on this. Here's the current set of proposals: >> >> 1. The merge becomes a two day activity. First day is merge, second >> day is fixing any failing layout tests. >> 2. We tag team people: first person does merge, next day another >> person fixes any failing layout tests. >> 3. One person for merge (like we do now), and failures are handled by >> owners of the layout tests. This assumes we can identify owners for >> buckets of layout tests so that folks know they are on the spot for a >> failing test. >> >> At this point we only care about regressions since 1.0, but that'll >> change soon. >> >> Can we make a decision on this at next weeks WebKit meeting? >> >> -Scott >> >> On Thu, Jan 15, 2009 at 1:03 PM, Brett Wilson >> wrote: >> > >> > I'm currently doing a 2-day merge rotation.As part of this, various >> > layout tests are regressing or getting added that I'm inserting into >> > the tests_fixable list. >> > >> > But, like every other layout test fixer, after my merges are done, >> > I'll finally go back to my old work and not think about it any more. >> > This is how we get a monotonically increasing list of broken tests >> at >> > the end of the tests fixable. I'm pretty certain this happens faster >> > than the tests are getting fixed because nobody wants to fix them. >> I'm >> > sort of tempted to just fix the ones my merge broke now, but that >> will >> > put me behind for my next merge, so I don't do that. >> > >> > I propose a different rotation schedule for WebKit merges. You would >> > do one day of merges, and the next day you would have to clean up >> all >> > the regressed and new layout tests your merge introduced. The layout >> > tests usually aren't that hard, so it normally wouldn't take the >> whole >> > day. This way we can be in a good steady state of WebKit merges. It >> > should also have a big advantage for fixing the broken tests since >> the >> > things that changed, the build numbers involved, etc. are still >> fresh >> > in the merger's head, and it won't be like approaching a random >> layout >> > test from the list with no context. >> > >> > The disadvantage of doing this is that we have to find people to do >> > the merges faster (we should probably formalize the schedule), and >> > you'll lose some advantage the second day of having all the >> > instructions and gotchas of the merge fresh in your mind. I was >> > thinking of a 3 day schedule (2 days of merging
[chromium-dev] Re: 2-day merges and the cleanup schedule
The process I was picturing is that we'd have a WebKit sheriff. That person would be in charge of keeping the build with latest webkit green and updating the webkit revision we pull once a day. If someone else needs a newer webkit revision (e.g. something they just committed), they can work with the WebKit sherriff to pull it in. But basically, it would be that person's job to either rebaseline failing tests or add them to the fixable list and assign them to someone to fix. Ojan On Wed, Mar 4, 2009 at 5:01 PM, David Levin wrote: > Yes, so what would be the process then? (Will we still have "mergers" > whose job is mostly to handle new and modified layout tests?) > > On Wed, Mar 4, 2009 at 4:58 PM, Ojan Vafai wrote: > >> Even once pulling in a new webkit is as simple as changing a revision >> number in DEPS, we'll still have new and modified layout tests that we'll >> need to deal with. >> >> >> On Wed, Mar 4, 2009 at 4:44 PM, David Levin wrote: >> >>> Aren't we trying to get rid of the merge process (soon-ish)? >>> If so, how would layout tests get fixed at that point? >>> >>> Dave >>> >>> On Wed, Mar 4, 2009 at 3:18 PM, Darin Fisher wrote: >>> I think the merger should be responsible for ensuring that any layout test fallout from the merge gets resolved. This doesn't mean necessary fixing everything, but rather it can be mean reaching out to others for help. I think the merger has to have incentive not to create a big mess with the merge and to also make sure the job gets done completely :-) -Darin On Wed, Mar 4, 2009 at 10:06 AM, Scott Violet wrote: > > If we are ever to keep up to date with layout tests we need to come to > a consensus on this. Here's the current set of proposals: > > 1. The merge becomes a two day activity. First day is merge, second > day is fixing any failing layout tests. > 2. We tag team people: first person does merge, next day another > person fixes any failing layout tests. > 3. One person for merge (like we do now), and failures are handled by > owners of the layout tests. This assumes we can identify owners for > buckets of layout tests so that folks know they are on the spot for a > failing test. > > At this point we only care about regressions since 1.0, but that'll > change soon. > > Can we make a decision on this at next weeks WebKit meeting? > > -Scott > > On Thu, Jan 15, 2009 at 1:03 PM, Brett Wilson > wrote: > > > > I'm currently doing a 2-day merge rotation.As part of this, various > > layout tests are regressing or getting added that I'm inserting into > > the tests_fixable list. > > > > But, like every other layout test fixer, after my merges are done, > > I'll finally go back to my old work and not think about it any more. > > This is how we get a monotonically increasing list of broken tests at > > the end of the tests fixable. I'm pretty certain this happens faster > > than the tests are getting fixed because nobody wants to fix them. > I'm > > sort of tempted to just fix the ones my merge broke now, but that > will > > put me behind for my next merge, so I don't do that. > > > > I propose a different rotation schedule for WebKit merges. You would > > do one day of merges, and the next day you would have to clean up all > > the regressed and new layout tests your merge introduced. The layout > > tests usually aren't that hard, so it normally wouldn't take the > whole > > day. This way we can be in a good steady state of WebKit merges. It > > should also have a big advantage for fixing the broken tests since > the > > things that changed, the build numbers involved, etc. are still fresh > > in the merger's head, and it won't be like approaching a random > layout > > test from the list with no context. > > > > The disadvantage of doing this is that we have to find people to do > > the merges faster (we should probably formalize the schedule), and > > you'll lose some advantage the second day of having all the > > instructions and gotchas of the merge fresh in your mind. I was > > thinking of a 3 day schedule (2 days of merging, 1 day of fixing) but > > that seems too heavyweight for the people volunteering to do this. > > > > Anybody have any comments? > > Brett > > > > > > > > > > >>> >>> >>> >>> >> > --~--~-~--~~~---~--~~ 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: 2-day merges and the cleanup schedule
Yes, so what would be the process then? (Will we still have "mergers" whose job is mostly to handle new and modified layout tests?) On Wed, Mar 4, 2009 at 4:58 PM, Ojan Vafai wrote: > Even once pulling in a new webkit is as simple as changing a revision > number in DEPS, we'll still have new and modified layout tests that we'll > need to deal with. > > > On Wed, Mar 4, 2009 at 4:44 PM, David Levin wrote: > >> Aren't we trying to get rid of the merge process (soon-ish)? >> If so, how would layout tests get fixed at that point? >> >> Dave >> >> On Wed, Mar 4, 2009 at 3:18 PM, Darin Fisher wrote: >> >>> I think the merger should be responsible for ensuring that any layout >>> test fallout from the merge gets resolved. This doesn't mean necessary >>> fixing everything, but rather it can be mean reaching out to others for >>> help. >>> I think the merger has to have incentive not to create a big mess with >>> the merge and to also make sure the job gets done completely :-) >>> >>> -Darin >>> >>> >>> On Wed, Mar 4, 2009 at 10:06 AM, Scott Violet wrote: >>> If we are ever to keep up to date with layout tests we need to come to a consensus on this. Here's the current set of proposals: 1. The merge becomes a two day activity. First day is merge, second day is fixing any failing layout tests. 2. We tag team people: first person does merge, next day another person fixes any failing layout tests. 3. One person for merge (like we do now), and failures are handled by owners of the layout tests. This assumes we can identify owners for buckets of layout tests so that folks know they are on the spot for a failing test. At this point we only care about regressions since 1.0, but that'll change soon. Can we make a decision on this at next weeks WebKit meeting? -Scott On Thu, Jan 15, 2009 at 1:03 PM, Brett Wilson wrote: > > I'm currently doing a 2-day merge rotation.As part of this, various > layout tests are regressing or getting added that I'm inserting into > the tests_fixable list. > > But, like every other layout test fixer, after my merges are done, > I'll finally go back to my old work and not think about it any more. > This is how we get a monotonically increasing list of broken tests at > the end of the tests fixable. I'm pretty certain this happens faster > than the tests are getting fixed because nobody wants to fix them. I'm > sort of tempted to just fix the ones my merge broke now, but that will > put me behind for my next merge, so I don't do that. > > I propose a different rotation schedule for WebKit merges. You would > do one day of merges, and the next day you would have to clean up all > the regressed and new layout tests your merge introduced. The layout > tests usually aren't that hard, so it normally wouldn't take the whole > day. This way we can be in a good steady state of WebKit merges. It > should also have a big advantage for fixing the broken tests since the > things that changed, the build numbers involved, etc. are still fresh > in the merger's head, and it won't be like approaching a random layout > test from the list with no context. > > The disadvantage of doing this is that we have to find people to do > the merges faster (we should probably formalize the schedule), and > you'll lose some advantage the second day of having all the > instructions and gotchas of the merge fresh in your mind. I was > thinking of a 3 day schedule (2 days of merging, 1 day of fixing) but > that seems too heavyweight for the people volunteering to do this. > > Anybody have any comments? > Brett > > > > >>> >>> >>> >> >> >> >> > --~--~-~--~~~---~--~~ 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: 2-day merges and the cleanup schedule
Even once pulling in a new webkit is as simple as changing a revision number in DEPS, we'll still have new and modified layout tests that we'll need to deal with. On Wed, Mar 4, 2009 at 4:44 PM, David Levin wrote: > Aren't we trying to get rid of the merge process (soon-ish)? > If so, how would layout tests get fixed at that point? > > Dave > > On Wed, Mar 4, 2009 at 3:18 PM, Darin Fisher wrote: > >> I think the merger should be responsible for ensuring that any layout test >> fallout from the merge gets resolved. This doesn't mean necessary fixing >> everything, but rather it can be mean reaching out to others for help. >> I think the merger has to have incentive not to create a big mess with the >> merge and to also make sure the job gets done completely :-) >> >> -Darin >> >> >> On Wed, Mar 4, 2009 at 10:06 AM, Scott Violet wrote: >> >>> >>> If we are ever to keep up to date with layout tests we need to come to >>> a consensus on this. Here's the current set of proposals: >>> >>> 1. The merge becomes a two day activity. First day is merge, second >>> day is fixing any failing layout tests. >>> 2. We tag team people: first person does merge, next day another >>> person fixes any failing layout tests. >>> 3. One person for merge (like we do now), and failures are handled by >>> owners of the layout tests. This assumes we can identify owners for >>> buckets of layout tests so that folks know they are on the spot for a >>> failing test. >>> >>> At this point we only care about regressions since 1.0, but that'll >>> change soon. >>> >>> Can we make a decision on this at next weeks WebKit meeting? >>> >>> -Scott >>> >>> On Thu, Jan 15, 2009 at 1:03 PM, Brett Wilson >>> wrote: >>> > >>> > I'm currently doing a 2-day merge rotation.As part of this, various >>> > layout tests are regressing or getting added that I'm inserting into >>> > the tests_fixable list. >>> > >>> > But, like every other layout test fixer, after my merges are done, >>> > I'll finally go back to my old work and not think about it any more. >>> > This is how we get a monotonically increasing list of broken tests at >>> > the end of the tests fixable. I'm pretty certain this happens faster >>> > than the tests are getting fixed because nobody wants to fix them. I'm >>> > sort of tempted to just fix the ones my merge broke now, but that will >>> > put me behind for my next merge, so I don't do that. >>> > >>> > I propose a different rotation schedule for WebKit merges. You would >>> > do one day of merges, and the next day you would have to clean up all >>> > the regressed and new layout tests your merge introduced. The layout >>> > tests usually aren't that hard, so it normally wouldn't take the whole >>> > day. This way we can be in a good steady state of WebKit merges. It >>> > should also have a big advantage for fixing the broken tests since the >>> > things that changed, the build numbers involved, etc. are still fresh >>> > in the merger's head, and it won't be like approaching a random layout >>> > test from the list with no context. >>> > >>> > The disadvantage of doing this is that we have to find people to do >>> > the merges faster (we should probably formalize the schedule), and >>> > you'll lose some advantage the second day of having all the >>> > instructions and gotchas of the merge fresh in your mind. I was >>> > thinking of a 3 day schedule (2 days of merging, 1 day of fixing) but >>> > that seems too heavyweight for the people volunteering to do this. >>> > >>> > Anybody have any comments? >>> > Brett >>> > >>> > > >>> > >>> >>> >>> >> >> >> > > > > --~--~-~--~~~---~--~~ 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: 2-day merges and the cleanup schedule
Define "resolved". Is filing and assigning a bug sufficient? It's not efficient to have whoever volunteers to do a merge personally pester people to fix the resulting test errors forever after. Whatever we do, we're going to have broken layout tests after a merge. Easy "fixes" -- re-baselining the ones that are actually all right, and filing specific bugs for the rest -- are definitely part of the merge task. But we don't want to put too much blame on the messenger: if a bunch of tests really break, or new tests don't pass, it's hardly the fault of the person who happened to bring the changes in. - Pam On Wed, Mar 4, 2009 at 3:18 PM, Darin Fisher wrote: > I think the merger should be responsible for ensuring that any layout test > fallout from the merge gets resolved. This doesn't mean necessary fixing > everything, but rather it can be mean reaching out to others for help. > I think the merger has to have incentive not to create a big mess with the > merge and to also make sure the job gets done completely :-) > > -Darin > > > On Wed, Mar 4, 2009 at 10:06 AM, Scott Violet wrote: > >> >> If we are ever to keep up to date with layout tests we need to come to >> a consensus on this. Here's the current set of proposals: >> >> 1. The merge becomes a two day activity. First day is merge, second >> day is fixing any failing layout tests. >> 2. We tag team people: first person does merge, next day another >> person fixes any failing layout tests. >> 3. One person for merge (like we do now), and failures are handled by >> owners of the layout tests. This assumes we can identify owners for >> buckets of layout tests so that folks know they are on the spot for a >> failing test. >> >> At this point we only care about regressions since 1.0, but that'll change >> soon. >> >> Can we make a decision on this at next weeks WebKit meeting? >> >> -Scott >> >> On Thu, Jan 15, 2009 at 1:03 PM, Brett Wilson >> wrote: >> > >> > I'm currently doing a 2-day merge rotation.As part of this, various >> > layout tests are regressing or getting added that I'm inserting into >> > the tests_fixable list. >> > >> > But, like every other layout test fixer, after my merges are done, >> > I'll finally go back to my old work and not think about it any more. >> > This is how we get a monotonically increasing list of broken tests at >> > the end of the tests fixable. I'm pretty certain this happens faster >> > than the tests are getting fixed because nobody wants to fix them. I'm >> > sort of tempted to just fix the ones my merge broke now, but that will >> > put me behind for my next merge, so I don't do that. >> > >> > I propose a different rotation schedule for WebKit merges. You would >> > do one day of merges, and the next day you would have to clean up all >> > the regressed and new layout tests your merge introduced. The layout >> > tests usually aren't that hard, so it normally wouldn't take the whole >> > day. This way we can be in a good steady state of WebKit merges. It >> > should also have a big advantage for fixing the broken tests since the >> > things that changed, the build numbers involved, etc. are still fresh >> > in the merger's head, and it won't be like approaching a random layout >> > test from the list with no context. >> > >> > The disadvantage of doing this is that we have to find people to do >> > the merges faster (we should probably formalize the schedule), and >> > you'll lose some advantage the second day of having all the >> > instructions and gotchas of the merge fresh in your mind. I was >> > thinking of a 3 day schedule (2 days of merging, 1 day of fixing) but >> > that seems too heavyweight for the people volunteering to do this. >> > >> > Anybody have any comments? >> > Brett >> > >> > > >> > >> >> >> > > > > --~--~-~--~~~---~--~~ 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: 2-day merges and the cleanup schedule
Aren't we trying to get rid of the merge process (soon-ish)? If so, how would layout tests get fixed at that point? Dave On Wed, Mar 4, 2009 at 3:18 PM, Darin Fisher wrote: > I think the merger should be responsible for ensuring that any layout test > fallout from the merge gets resolved. This doesn't mean necessary fixing > everything, but rather it can be mean reaching out to others for help. > I think the merger has to have incentive not to create a big mess with the > merge and to also make sure the job gets done completely :-) > > -Darin > > > On Wed, Mar 4, 2009 at 10:06 AM, Scott Violet wrote: > >> >> If we are ever to keep up to date with layout tests we need to come to >> a consensus on this. Here's the current set of proposals: >> >> 1. The merge becomes a two day activity. First day is merge, second >> day is fixing any failing layout tests. >> 2. We tag team people: first person does merge, next day another >> person fixes any failing layout tests. >> 3. One person for merge (like we do now), and failures are handled by >> owners of the layout tests. This assumes we can identify owners for >> buckets of layout tests so that folks know they are on the spot for a >> failing test. >> >> At this point we only care about regressions since 1.0, but that'll change >> soon. >> >> Can we make a decision on this at next weeks WebKit meeting? >> >> -Scott >> >> On Thu, Jan 15, 2009 at 1:03 PM, Brett Wilson >> wrote: >> > >> > I'm currently doing a 2-day merge rotation.As part of this, various >> > layout tests are regressing or getting added that I'm inserting into >> > the tests_fixable list. >> > >> > But, like every other layout test fixer, after my merges are done, >> > I'll finally go back to my old work and not think about it any more. >> > This is how we get a monotonically increasing list of broken tests at >> > the end of the tests fixable. I'm pretty certain this happens faster >> > than the tests are getting fixed because nobody wants to fix them. I'm >> > sort of tempted to just fix the ones my merge broke now, but that will >> > put me behind for my next merge, so I don't do that. >> > >> > I propose a different rotation schedule for WebKit merges. You would >> > do one day of merges, and the next day you would have to clean up all >> > the regressed and new layout tests your merge introduced. The layout >> > tests usually aren't that hard, so it normally wouldn't take the whole >> > day. This way we can be in a good steady state of WebKit merges. It >> > should also have a big advantage for fixing the broken tests since the >> > things that changed, the build numbers involved, etc. are still fresh >> > in the merger's head, and it won't be like approaching a random layout >> > test from the list with no context. >> > >> > The disadvantage of doing this is that we have to find people to do >> > the merges faster (we should probably formalize the schedule), and >> > you'll lose some advantage the second day of having all the >> > instructions and gotchas of the merge fresh in your mind. I was >> > thinking of a 3 day schedule (2 days of merging, 1 day of fixing) but >> > that seems too heavyweight for the people volunteering to do this. >> > >> > Anybody have any comments? >> > Brett >> > >> > > >> > >> >> >> > > > > --~--~-~--~~~---~--~~ 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: 2-day merges and the cleanup schedule
I think the merger should be responsible for ensuring that any layout test fallout from the merge gets resolved. This doesn't mean necessary fixing everything, but rather it can be mean reaching out to others for help. I think the merger has to have incentive not to create a big mess with the merge and to also make sure the job gets done completely :-) -Darin On Wed, Mar 4, 2009 at 10:06 AM, Scott Violet wrote: > > If we are ever to keep up to date with layout tests we need to come to > a consensus on this. Here's the current set of proposals: > > 1. The merge becomes a two day activity. First day is merge, second > day is fixing any failing layout tests. > 2. We tag team people: first person does merge, next day another > person fixes any failing layout tests. > 3. One person for merge (like we do now), and failures are handled by > owners of the layout tests. This assumes we can identify owners for > buckets of layout tests so that folks know they are on the spot for a > failing test. > > At this point we only care about regressions since 1.0, but that'll change > soon. > > Can we make a decision on this at next weeks WebKit meeting? > > -Scott > > On Thu, Jan 15, 2009 at 1:03 PM, Brett Wilson wrote: > > > > I'm currently doing a 2-day merge rotation.As part of this, various > > layout tests are regressing or getting added that I'm inserting into > > the tests_fixable list. > > > > But, like every other layout test fixer, after my merges are done, > > I'll finally go back to my old work and not think about it any more. > > This is how we get a monotonically increasing list of broken tests at > > the end of the tests fixable. I'm pretty certain this happens faster > > than the tests are getting fixed because nobody wants to fix them. I'm > > sort of tempted to just fix the ones my merge broke now, but that will > > put me behind for my next merge, so I don't do that. > > > > I propose a different rotation schedule for WebKit merges. You would > > do one day of merges, and the next day you would have to clean up all > > the regressed and new layout tests your merge introduced. The layout > > tests usually aren't that hard, so it normally wouldn't take the whole > > day. This way we can be in a good steady state of WebKit merges. It > > should also have a big advantage for fixing the broken tests since the > > things that changed, the build numbers involved, etc. are still fresh > > in the merger's head, and it won't be like approaching a random layout > > test from the list with no context. > > > > The disadvantage of doing this is that we have to find people to do > > the merges faster (we should probably formalize the schedule), and > > you'll lose some advantage the second day of having all the > > instructions and gotchas of the merge fresh in your mind. I was > > thinking of a 3 day schedule (2 days of merging, 1 day of fixing) but > > that seems too heavyweight for the people volunteering to do this. > > > > Anybody have any comments? > > Brett > > > > > > > > > > > --~--~-~--~~~---~--~~ 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: Readability mode prototyped in the wild
On 4-Mar-09, at 4:38 PM, Evan Martin wrote: > > Here's the core of that implementation: > http://lab.arc90.com/experiments/readability/js/readability-0.1.js > > It's heuristic-based, e.g.: > // Study all the paragraphs and find the chunk that has the most > 's and keep it: For what it's worth, there are several reports on LifeHacker that the selected heuristic doesn't end up working for a lot of pages, but it's a clever start, to be sure. >> I continue to feel that this is a huge use case for browsers and >> something >> like this could be a major boon if the UI was right. Agreed. I think you'd need clearer controls about how to get back to the full page, and probably a smooth transition from "full page" to "selected bit" that uses visual momentum to keep the user's context. Something similar to how the lightboxes on many websites use now, but perhaps without the 3-d effect. Also, it might be powerful to let the user indicate the aspect of the page they want to focus on. cheers, mike --~--~-~--~~~---~--~~ 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: Mac Dogfood Planning
On Mon, Mar 2, 2009 at 2:27 PM, Mike Pinkerton wrote: > Let's hold off picking what we're working on until we've agreed this > is the right list. I've turned this list into bugs in our bugtracker with a label of "Dogfood" http://code.google.com/p/chromium/issues/list?q=label:mac%20label:dogfood This way it's pretty easy to see what we have left. Feel free to claim something if it has no owner, those haven't been spoken for. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Streamlining key events
This finally successfully landed in r10918 and r10919. Please let me know if something comes up from this. Avi On Wed, Feb 25, 2009 at 2:15 PM, Avi Drissman wrote: > If you never use the keyboard in Chromium, you can skip this email. > > I'm going to land http://codereview.chromium.org/27056 which fixes most of > the glaring problems with keyboard support on the Mac by unifying and > streamlining key events for everyone. If things don't work for you, it's > probably my fault. Wanted to give a heads-up. > > Avi > --~--~-~--~~~---~--~~ 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: Readability mode prototyped in the wild
Here's the core of that implementation: http://lab.arc90.com/experiments/readability/js/readability-0.1.js It's heuristic-based, e.g.: // Study all the paragraphs and find the chunk that has the most 's and keep it: On Tue, Mar 3, 2009 at 2:00 PM, Peter Kasting wrote: > Googlers may remember that one of my brainstorm ideas for Chromium was > "readability mode", a way to temporarily get rid of everything on a page > except the main article. Now a company has prototyped this in the wild > using a bookmarklet. Watch the intro video here. > http://lab.arc90.com/2009/03/readability.php > > I continue to feel that this is a huge use case for browsers and something > like this could be a major boon if the UI was right. > PK > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Readability mode prototyped in the wild
Googlers may remember that one of my brainstorm ideas for Chromium was "readability mode", a way to temporarily get rid of everything on a page except the main article. Now a company has prototyped this in the wild using a bookmarklet. Watch the intro video here. http://lab.arc90.com/2009/03/readability.php I continue to feel that this is a huge use case for browsers and something like this could be a major boon if the UI was right. PK --~--~-~--~~~---~--~~ 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: 2-day merges and the cleanup schedule
If we are ever to keep up to date with layout tests we need to come to a consensus on this. Here's the current set of proposals: 1. The merge becomes a two day activity. First day is merge, second day is fixing any failing layout tests. 2. We tag team people: first person does merge, next day another person fixes any failing layout tests. 3. One person for merge (like we do now), and failures are handled by owners of the layout tests. This assumes we can identify owners for buckets of layout tests so that folks know they are on the spot for a failing test. At this point we only care about regressions since 1.0, but that'll change soon. Can we make a decision on this at next weeks WebKit meeting? -Scott On Thu, Jan 15, 2009 at 1:03 PM, Brett Wilson wrote: > > I'm currently doing a 2-day merge rotation.As part of this, various > layout tests are regressing or getting added that I'm inserting into > the tests_fixable list. > > But, like every other layout test fixer, after my merges are done, > I'll finally go back to my old work and not think about it any more. > This is how we get a monotonically increasing list of broken tests at > the end of the tests fixable. I'm pretty certain this happens faster > than the tests are getting fixed because nobody wants to fix them. I'm > sort of tempted to just fix the ones my merge broke now, but that will > put me behind for my next merge, so I don't do that. > > I propose a different rotation schedule for WebKit merges. You would > do one day of merges, and the next day you would have to clean up all > the regressed and new layout tests your merge introduced. The layout > tests usually aren't that hard, so it normally wouldn't take the whole > day. This way we can be in a good steady state of WebKit merges. It > should also have a big advantage for fixing the broken tests since the > things that changed, the build numbers involved, etc. are still fresh > in the merger's head, and it won't be like approaching a random layout > test from the list with no context. > > The disadvantage of doing this is that we have to find people to do > the merges faster (we should probably formalize the schedule), and > you'll lose some advantage the second day of having all the > instructions and gotchas of the merge fresh in your mind. I was > thinking of a 3 day schedule (2 days of merging, 1 day of fixing) but > that seems too heavyweight for the people volunteering to do this. > > Anybody have any comments? > Brett > > > > --~--~-~--~~~---~--~~ 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: What's the deal temp_scaffolding_subs ?
Hi Mike, Ben and I have been working on deleting the other tab contents types. TabContents can't be fixed until these are all deleted, which will be a while longer. Brett --~--~-~--~~~---~--~~ 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: What's the deal temp_scaffolding_subs ?
Just following up, I'll start whacking on TabContents as soon as I can get a patch landed that overlaps with temp_scaffolding_stubs. Of course, that means the tree will have to open for more than 15 minutes :-). The faster we can get TabContents out of that file, the better. On Wed, Mar 4, 2009 at 9:41 AM, Mike Pinkerton wrote: > Well, its not *verbatim*, but it is starting to converge on the real > thing. Here's the history: > > When we started porting the front-ends, we just stubbed the big > classes enough to get it limping, filling in empty declarations to > avoid de-HWNDifying everything and dragging in tons of headers that > weren't yet really needed. This worked quite well. TabContents was a > major piece, but it had a lot of Win32 dependencies with the native UI > pages (download manager, history, etc). We were able to get quite far > with just a stub of TabContents and not the real McCoy. We considered > fleshing out the real one, but it was always on the verge of going > away as Glen moved the native UIs to HTML. Once everything was HTML, > we'd only need WebContents and TabContents could fade into > obsolescence, thus no need to spend much time on it. > > As we started hooking up more and more functionality, however, > TabContents grew bigger and bigger. And bigger. And became more and > more like its counterpart, just lacking in all the right places to > drive you mad. This is something that's been in the back of my mind to > clean up, I've just been distracted with other stuff. I will talk to > Glen and Brett about if we're in the right place to get rid of it, or > just port it once and for all. > > Hope that helps. > > On Wed, Mar 4, 2009 at 7:33 AM, Dean McNamee wrote: >> >> I am working on Linux omnibox, and chasing a stupid crash into >> temp_scaffolding_stubs.cc (TabContents). >> >> Every method I looked at was just a copy and paste from >> tab_contents.cc, without any modifications. Why? Why are we not just >> using the code in tab_contents.cc ? There is just a massive ifdef >> around it, with no comment as to what doesn't work, why it copied >> verbatim into stubs, etc. Totally confused. >> >> Thanks >> -- dean >> >> >> >> > > > > -- > Mike Pinkerton > Mac Weenie > pinker...@google.com > -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: What's the deal temp_scaffolding_subs ?
Well, its not *verbatim*, but it is starting to converge on the real thing. Here's the history: When we started porting the front-ends, we just stubbed the big classes enough to get it limping, filling in empty declarations to avoid de-HWNDifying everything and dragging in tons of headers that weren't yet really needed. This worked quite well. TabContents was a major piece, but it had a lot of Win32 dependencies with the native UI pages (download manager, history, etc). We were able to get quite far with just a stub of TabContents and not the real McCoy. We considered fleshing out the real one, but it was always on the verge of going away as Glen moved the native UIs to HTML. Once everything was HTML, we'd only need WebContents and TabContents could fade into obsolescence, thus no need to spend much time on it. As we started hooking up more and more functionality, however, TabContents grew bigger and bigger. And bigger. And became more and more like its counterpart, just lacking in all the right places to drive you mad. This is something that's been in the back of my mind to clean up, I've just been distracted with other stuff. I will talk to Glen and Brett about if we're in the right place to get rid of it, or just port it once and for all. Hope that helps. On Wed, Mar 4, 2009 at 7:33 AM, Dean McNamee wrote: > > I am working on Linux omnibox, and chasing a stupid crash into > temp_scaffolding_stubs.cc (TabContents). > > Every method I looked at was just a copy and paste from > tab_contents.cc, without any modifications. Why? Why are we not just > using the code in tab_contents.cc ? There is just a massive ifdef > around it, with no comment as to what doesn't work, why it copied > verbatim into stubs, etc. Totally confused. > > Thanks > -- dean > > > > -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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's the deal temp_scaffolding_subs ?
I am working on Linux omnibox, and chasing a stupid crash into temp_scaffolding_stubs.cc (TabContents). Every method I looked at was just a copy and paste from tab_contents.cc, without any modifications. Why? Why are we not just using the code in tab_contents.cc ? There is just a massive ifdef around it, with no comment as to what doesn't work, why it copied verbatim into stubs, etc. Totally confused. Thanks -- dean --~--~-~--~~~---~--~~ 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: Inline PDF Support
Although converting a pdf to PNG/HTML automatically in Chrome is very cool, but I don't think it's a good idea. Maybe there will have a pdf plugin can do it. Brower should do the simplest thing we care about, that is view web page. And other things can be got by plugins or some other schemas. So, where is Chrome's plugin? On Mar 3, 4:01 pm, Daniel wrote: > Hi guys, > > Are there any plans to support the viewing of PDF documents (inline/ > natively) within chromium without the need for an external app/plugin > like acrobat...i.e. kinda like how Safari does it on mac? > alternatively, some manner of first converting them to PNG/HTML/etc? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
