[chromium-dev] Re: V8Bindings_prebuild slowness

[Pam Greene]

On Fri, Jan 9, 2009 at 3:37 PM, Darin Fisher  wrote:

>
>
> On Sun, Jan 4, 2009 at 5:44 PM,  wrote:
>
>>
>> On Sun, 4 Jan 2009, Brett Wilson wrote:
>>
>> >
>> > On Sun, Jan 4, 2009 at 1:23 PM, Darin Fisher 
>> wrote:
>> > > This problem could also be solved by ignoring DerivedSources.make, and
>> > > instead just add the "source" files to the vcproj.  Then write a
>> custom
>> > > .rules file for each file type that runs the appropriate batch command
>> to
>> > > create the generated file.  Then, dependency tracking would work just
>> as it
>> > > does for .cpp files.
>> >
>> > Well, but you'd still have the slowness of spawing perl hundreds of
>> > times. I'm not sure that would speed up the build at all (though it
>> > would improve the dependency management).
>>
>> But you would only pay it once.  Using native vcproj files may get the
>> dependencies right and maybe you wouldn't need to do a full rebuild after
>> each sync then.  Or maybe I put too much faith in MSVC's dependency
>> management.
>>
>
> Right.  This is what I was thinking too.  I do clobber builds primarily
> (only?) because of issues related to DerivedSources.
>
>
>
>>
>> > > Our DerivedSources.make is already so tremendously out of sync with
>> the one
>> > > upstream that there doesn't seem to be much point in using it.
>> >
>> > I agree.
>>
>> It's not used in the scons build which properly tracks dependencies so
>> the files are only generated once.  Would Incredibuild be able to
>> parallelize the perl scripts or does it only know how to parallelize c++
>> compiles?
>>
>
> That's a great question :)
>
> I suspect it only runs those locally.
>

Without an additional extension license, only locally.  But if it only had
to do it once, that'd still be a big help.  Alternatively, if we find we
still need to speed clobber builds and are willing to move away from
DerivedSources.make, I'd expect that only launching perl once rather than
200+ times -- just move the "do this for every file in this long list" from
make into perl -- would provide a dramatic speedup.

- Pam


>
> -Darin
>
>
> >
>

--~--~-~--~~~---~--~~
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: V8Bindings_prebuild slowness

[Eric Seidel]

There have long been talks of re-writing the idl bindings auto-gen
system, it's just not been done yet.  I'm sure WebKit folks would be
happy for any work in the area.

-eric

On Fri, Jan 9, 2009 at 3:37 PM, Darin Fisher  wrote:
>
>
> On Sun, Jan 4, 2009 at 5:44 PM,  wrote:
>>
>> On Sun, 4 Jan 2009, Brett Wilson wrote:
>>
>> >
>> > On Sun, Jan 4, 2009 at 1:23 PM, Darin Fisher  wrote:
>> > > This problem could also be solved by ignoring DerivedSources.make, and
>> > > instead just add the "source" files to the vcproj.  Then write a
>> > > custom
>> > > .rules file for each file type that runs the appropriate batch command
>> > > to
>> > > create the generated file.  Then, dependency tracking would work just
>> > > as it
>> > > does for .cpp files.
>> >
>> > Well, but you'd still have the slowness of spawing perl hundreds of
>> > times. I'm not sure that would speed up the build at all (though it
>> > would improve the dependency management).
>>
>> But you would only pay it once.  Using native vcproj files may get the
>> dependencies right and maybe you wouldn't need to do a full rebuild after
>> each sync then.  Or maybe I put too much faith in MSVC's dependency
>> management.
>
> Right.  This is what I was thinking too.  I do clobber builds primarily
> (only?) because of issues related to DerivedSources.
>
>>
>> > > Our DerivedSources.make is already so tremendously out of sync with
>> > > the one
>> > > upstream that there doesn't seem to be much point in using it.
>> >
>> > I agree.
>>
>> It's not used in the scons build which properly tracks dependencies so
>> the files are only generated once.  Would Incredibuild be able to
>> parallelize the perl scripts or does it only know how to parallelize c++
>> compiles?
>
> That's a great question :)
> I suspect it only runs those locally.
> -Darin
>
>
> >
>

--~--~-~--~~~---~--~~
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: V8Bindings_prebuild slowness

[Darin Fisher]

On Sun, Jan 4, 2009 at 5:44 PM,  wrote:

>
> On Sun, 4 Jan 2009, Brett Wilson wrote:
>
> >
> > On Sun, Jan 4, 2009 at 1:23 PM, Darin Fisher  wrote:
> > > This problem could also be solved by ignoring DerivedSources.make, and
> > > instead just add the "source" files to the vcproj.  Then write a custom
> > > .rules file for each file type that runs the appropriate batch command
> to
> > > create the generated file.  Then, dependency tracking would work just
> as it
> > > does for .cpp files.
> >
> > Well, but you'd still have the slowness of spawing perl hundreds of
> > times. I'm not sure that would speed up the build at all (though it
> > would improve the dependency management).
>
> But you would only pay it once.  Using native vcproj files may get the
> dependencies right and maybe you wouldn't need to do a full rebuild after
> each sync then.  Or maybe I put too much faith in MSVC's dependency
> management.
>

Right.  This is what I was thinking too.  I do clobber builds primarily
(only?) because of issues related to DerivedSources.



>
> > > Our DerivedSources.make is already so tremendously out of sync with the
> one
> > > upstream that there doesn't seem to be much point in using it.
> >
> > I agree.
>
> It's not used in the scons build which properly tracks dependencies so
> the files are only generated once.  Would Incredibuild be able to
> parallelize the perl scripts or does it only know how to parallelize c++
> compiles?
>

That's a great question :)

I suspect it only runs those locally.

-Darin

--~--~-~--~~~---~--~~
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: Getting started, getting blocked...

[Marc-Antoine Ruel]

Oh I broke integrated svn switch support in gclient lately and didn't
have time to fix it. Sorry. The tarball needs to be updated. :/

I'll try to do that next week.

Meanwhile,
rm -rf src/third_party/WebKit

M-A

On Fri, Jan 9, 2009 at 5:19 PM, Jaff  wrote:
>
> I decided to start fresh, and downloaded the source tar-ball. Then
> when I ran gclient sync, here is what I got:
>
> $ gclient sync 2>&1 | tee sync.log
>
>  running '/Users/mjaffe/Development/depot_tools/bin/../
> platform/mac/bin/svn update' in '/Users/mjaffe/Development/Chrome/
> chromium/src'
> UDEPS
> Updated to revision 7839.
>
>  running '/Users/mjaffe/Development/depot_tools/bin/../
> platform/mac/bin/svn switch -r 7838 /trunk/deps/third_party/WebKit src/
> third_party/WebKit' in '/Users/mjaffe/Development/Chrome/chromium'
> svn: '/trunk/deps/third_party/WebKit' does not appear to be a URL
> Error: failed to run command: /Users/mjaffe/Development/depot_tools/
> bin/../platform/mac/bin/svn switch -r 7838 /trunk/deps/third_party/
> WebKit src/third_party/WebKit
>
> Odd that this works for everyone else but not me.
>
> On Dec 19 2008, 4:21 pm, Marc-Antoine Ruel 
> wrote:
>> You've been updated since " svn: '.' is not a working copy " is an
>> error I recently introduced on non-Windows platforms. You can safely
>> ignore it.
>>
>> That's strange that you have svn version issues since we don't include
>> svn in the depot_tools on non-windows platform.
>>
>> FYI, svn 1.4 can't read checkouts created by svn 1.5. You somehow got
>> a svn 1.5 checkout and are currently using a 1.4 svn client.
>>
>> M-A
>>
>> On Fri, Dec 19, 2008 at 7:16 PM, Jaff  wrote:
>>
>> > OK, now I cannot even use svn anymore, trying to do a new client
>> > config yieds this error:
>>
>> > dhcp-172-19-240-54:~/Development/Google mjaffe$ gclient sync
>> > svn: '.' is not a working copy
>> > svn: This client is too old to work with working copy '/Users/mjaffe/
>> > Development/Google/src'; please get a newer Subversion client
>> > Traceback (most recent call last):
>> >  File "/Users/mjaffe/Development/chrome_depot_tools/release/
>> > gclient.py", line 1057, in 
>> >result = Main(sys.argv)
>> >  File "/Users/mjaffe/Development/chrome_depot_tools/release/
>> > gclient.py", line 1052, in Main
>> >return DispatchCommand(command, options, args)
>> >  File "/Users/mjaffe/Development/chrome_depot_tools/release/
>> > gclient.py", line 999, in DispatchCommand
>> >return command_map[command](options, args)
>> >  File "/Users/mjaffe/Development/chrome_depot_tools/release/
>> > gclient.py", line 950, in DoUpdate
>> >return client.RunOnDeps('update', args)
>> >  File "/Users/mjaffe/Development/chrome_depot_tools/release/
>> > gclient.py", line 834, in RunOnDeps
>> >scm.RunCommand(command, self._options, args)
>> >  File "/Users/mjaffe/Development/chrome_depot_tools/release/
>> > gclient.py", line 444, in RunCommand
>> >self.update(options, args)
>>
>> > I don't know what version of svn I should be using. Would not the one
>> > in my local tools dir work?
>>
>> > Mark
>> > On Dec 19, 1:30 pm, Jaff  wrote:
>> >> OK, here is the contents of .gclient
>>
>> >> # An element of this array (a "solution") describes a repository
>> >> directory that
>> >> # will be checked out into your working copy.  Each solution may
>> >> optionally define
>> >> # additional dependencies (via its DEPS file) to be checked out
>> >> alongside the
>> >> # solution's directory.  A solution may also specify custom
>> >> dependencies (via
>> >> # the "custom_deps" property) that override or augment the
>> >> dependencies
>> >> # specified by the DEPS file.
>> >> solutions = [
>> >>   { "name": "src",
>> >> "url" : "http://src.chromium.org/svn/trunk/src";,
>> >> "custom_deps" : {
>> >>   # To use the sandbox trunk instead, uncomment:
>> >>   #"sandbox": "https://svn/chrome/trunk/sandbox";,
>> >>   # To exclude the page_cycler from your working copy, uncomment:
>> >>   #"data/page_cycler": None,
>> >> }
>> >>   }
>> >> ]
>>
>> >> On Dec 19, 1:09 pm, "Mark Larson (Google)"  wrote:
>>
>> >> > On Fri, Dec 19, 2008 at 13:01, Jaff  wrote:
>>
>> >> > > Well, this is too strange. It would seem as if some other file-system
>> >> > > mechanism is cacheing
>> >> > > data. I created a new directory and attempted a fresh checkout, and it
>> >> > > crashes/halts in exactly the same place. Complains about src/
>> >> > > third_party/WebKit:
>>
>> >> > > svn: '/trunk/deps/third_party/web...@7278' does not appear to be a URL
>>
>> >> > It looks like a bad configuration in your .gclient. Can you post it?
>>
>> >> > > I need someone to confirm they can do a fresh checkout on a machine
>> >> > > which did not have the code on it already.
>>
>> >> > > Thanks,
>> >> > > me
>>
>> >> > > On Dec 18, 1:17 pm, Marc-Antoine Ruel  wrote:
>> >> > > > Probably my fault, let me confirm.
>>
>> >> > > > M-A
>>
>> >> > > > On Thu, Dec 18, 2008 at 3:34 PM, Jaff  wrote:

[chromium-dev] Re: Getting started, getting blocked...

[Jaff]

I decided to start fresh, and downloaded the source tar-ball. Then
when I ran gclient sync, here is what I got:

$ gclient sync 2>&1 | tee sync.log

 running '/Users/mjaffe/Development/depot_tools/bin/../
platform/mac/bin/svn update' in '/Users/mjaffe/Development/Chrome/
chromium/src'
UDEPS
Updated to revision 7839.

 running '/Users/mjaffe/Development/depot_tools/bin/../
platform/mac/bin/svn switch -r 7838 /trunk/deps/third_party/WebKit src/
third_party/WebKit' in '/Users/mjaffe/Development/Chrome/chromium'
svn: '/trunk/deps/third_party/WebKit' does not appear to be a URL
Error: failed to run command: /Users/mjaffe/Development/depot_tools/
bin/../platform/mac/bin/svn switch -r 7838 /trunk/deps/third_party/
WebKit src/third_party/WebKit

Odd that this works for everyone else but not me.

On Dec 19 2008, 4:21 pm, Marc-Antoine Ruel 
wrote:
> You've been updated since " svn: '.' is not a working copy " is an
> error I recently introduced on non-Windows platforms. You can safely
> ignore it.
>
> That's strange that you have svn version issues since we don't include
> svn in the depot_tools on non-windows platform.
>
> FYI, svn 1.4 can't read checkouts created by svn 1.5. You somehow got
> a svn 1.5 checkout and are currently using a 1.4 svn client.
>
> M-A
>
> On Fri, Dec 19, 2008 at 7:16 PM, Jaff  wrote:
>
> > OK, now I cannot even use svn anymore, trying to do a new client
> > config yieds this error:
>
> > dhcp-172-19-240-54:~/Development/Google mjaffe$ gclient sync
> > svn: '.' is not a working copy
> > svn: This client is too old to work with working copy '/Users/mjaffe/
> > Development/Google/src'; please get a newer Subversion client
> > Traceback (most recent call last):
> >  File "/Users/mjaffe/Development/chrome_depot_tools/release/
> > gclient.py", line 1057, in 
> >    result = Main(sys.argv)
> >  File "/Users/mjaffe/Development/chrome_depot_tools/release/
> > gclient.py", line 1052, in Main
> >    return DispatchCommand(command, options, args)
> >  File "/Users/mjaffe/Development/chrome_depot_tools/release/
> > gclient.py", line 999, in DispatchCommand
> >    return command_map[command](options, args)
> >  File "/Users/mjaffe/Development/chrome_depot_tools/release/
> > gclient.py", line 950, in DoUpdate
> >    return client.RunOnDeps('update', args)
> >  File "/Users/mjaffe/Development/chrome_depot_tools/release/
> > gclient.py", line 834, in RunOnDeps
> >    scm.RunCommand(command, self._options, args)
> >  File "/Users/mjaffe/Development/chrome_depot_tools/release/
> > gclient.py", line 444, in RunCommand
> >    self.update(options, args)
>
> > I don't know what version of svn I should be using. Would not the one
> > in my local tools dir work?
>
> > Mark
> > On Dec 19, 1:30 pm, Jaff  wrote:
> >> OK, here is the contents of .gclient
>
> >> # An element of this array (a "solution") describes a repository
> >> directory that
> >> # will be checked out into your working copy.  Each solution may
> >> optionally define
> >> # additional dependencies (via its DEPS file) to be checked out
> >> alongside the
> >> # solution's directory.  A solution may also specify custom
> >> dependencies (via
> >> # the "custom_deps" property) that override or augment the
> >> dependencies
> >> # specified by the DEPS file.
> >> solutions = [
> >>   { "name"        : "src",
> >>     "url"         : "http://src.chromium.org/svn/trunk/src";,
> >>     "custom_deps" : {
> >>       # To use the sandbox trunk instead, uncomment:
> >>       #"sandbox": "https://svn/chrome/trunk/sandbox";,
> >>       # To exclude the page_cycler from your working copy, uncomment:
> >>       #"data/page_cycler": None,
> >>     }
> >>   }
> >> ]
>
> >> On Dec 19, 1:09 pm, "Mark Larson (Google)"  wrote:
>
> >> > On Fri, Dec 19, 2008 at 13:01, Jaff  wrote:
>
> >> > > Well, this is too strange. It would seem as if some other file-system
> >> > > mechanism is cacheing
> >> > > data. I created a new directory and attempted a fresh checkout, and it
> >> > > crashes/halts in exactly the same place. Complains about src/
> >> > > third_party/WebKit:
>
> >> > > svn: '/trunk/deps/third_party/web...@7278' does not appear to be a URL
>
> >> > It looks like a bad configuration in your .gclient. Can you post it?
>
> >> > > I need someone to confirm they can do a fresh checkout on a machine
> >> > > which did not have the code on it already.
>
> >> > > Thanks,
> >> > > me
>
> >> > > On Dec 18, 1:17 pm, Marc-Antoine Ruel  wrote:
> >> > > > Probably my fault, let me confirm.
>
> >> > > > M-A
>
> >> > > > On Thu, Dec 18, 2008 at 3:34 PM, Jaff  wrote:
>
> >> > > > > Hi,
>
> >> > > > > I've been wanting to get into some contribution-mode, so I have 
> >> > > > > gotten
> >> > > > > far enough to download the source and make my environment 
> >> > > > > compatible
> >> > > > > (MacbookPro, 2.4GHz, 2Gb RAM). However, on Tuesday, the svn 
> >> > > > > repository
> >> > > > > seemed to be offline for about an hour or so while I was trying to 
> >> 

[chromium-dev] Re: Stabilization Effort Daily Report

[Evan Martin]

On Fri, Jan 9, 2009 at 11:32 AM, Jon  wrote:
> Be sure to sign up
> at http://spreadsheets.google.com/ccc?key=pMwul3Seofg448Q1VFJjsJA&hl=en if
> you are going to work on a layout test.  We don't want to step on each
> other's toes.

I just noticed Linux is on there.  Has anyone else been working on
Linux tests off of that sheet?  I've just been fixing them directly
and making my changes (and notes) on tests_fixable.txt.

--~--~-~--~~~---~--~~
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: Context menu for title bar doesn't appear when a tab's context menu was open

[DeArto20]

I wanted to know how others in this group think about my suggestion
about above bug (issue 5695), If it is reasonable or not.

On 1월10일, 오전1시49분, Peter Kasting  wrote:
> On Fri, Jan 9, 2009 at 6:13 AM, DeArto20  wrote:
> > The following is the reply written by me on bugtracker - Issue 5695.
>
> So... why are you mailing it to this list?
>
> 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: Context menu for title bar doesn't appear when a tab's context menu was open

[DeArto20]

I wanted know how others in this group think about my suggestion about
above bug (issue 5695),
If it is reasonable or not.

On 1월10일, 오전1시49분, Peter Kasting  wrote:
> On Fri, Jan 9, 2009 at 6:13 AM, DeArto20  wrote:
> > The following is the reply written by me on bugtracker - Issue 5695.
>
> So... why are you mailing it to this list?
>
> 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] Stabilization Effort Daily Report

[Jon]

*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 :
REGRESSION:
bad drop-shadow rendering

 Issue 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=pMwul3Seofg448Q1VFJjsJA&hl=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]



[image: History of passing tests
%]
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] Re: The Process Question: How do we change WebKit code?

[Dimitri Glazkov]

http://sites.google.com/a/chromium.org/dev/developers/webkit-changes

:DG<

On Fri, Jan 9, 2009 at 11:15 AM, Dimitri Glazkov  wrote:
> Dear People of Chromium,
>
> I've been thinking about the process of making changes to WebKit code
> in a logical and consistent fashion (note, that doesn't necessarily
> preclude "sane").
>
> Until we've switched to the integration model, we are still in a
> vendor branch state and thus the process of tweaking WebKit code is
> not what you call a "that-was-easy" effort. Nevertheless, we must have
> a somewhat trivialized way of doing it.
>
> Here's what I've come up so far:
>
> A. If the change is to common code (WebCore proper,
> JavaScriptCore/wtf), make it upstream -- it will be picked up by our
> daily merges.
>
> B. If the change is to our port (platform/graphics/skia|chromium,
> etc.), you can do the following:
>
> 1) make the change downstream and make sure it doesn't break anything
> 2) submit the change upstream and get it reviewed/committed
> 3) reconcile any deltas that may have occurred during review process
> -- the merge custodian will thank you.
>
> The basic difference is making sure that the changes to our port work
> before they go upstream. It would certainly be more frustrating to
> wait for the daily merge to pick up your tweaks and find out that they
> were wrong.
>
> However, let's try to avoid situations where the change is stuck in
> WebKit review limbo or abandoned, leaving forked files in our vendor
> branch. I am not sure whether we need any special rules for these,
> aside from the occasional stark glare from the merge people.
>
> What do you think? Good rules, bad rules? Comments? Questions? Quirky
> and entertaining remarks?
>
> :DG<
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] The Process Question: How do we change WebKit code?

[Dimitri Glazkov]

Dear People of Chromium,

I've been thinking about the process of making changes to WebKit code
in a logical and consistent fashion (note, that doesn't necessarily
preclude "sane").

Until we've switched to the integration model, we are still in a
vendor branch state and thus the process of tweaking WebKit code is
not what you call a "that-was-easy" effort. Nevertheless, we must have
a somewhat trivialized way of doing it.

Here's what I've come up so far:

A. If the change is to common code (WebCore proper,
JavaScriptCore/wtf), make it upstream -- it will be picked up by our
daily merges.

B. If the change is to our port (platform/graphics/skia|chromium,
etc.), you can do the following:

1) make the change downstream and make sure it doesn't break anything
2) submit the change upstream and get it reviewed/committed
3) reconcile any deltas that may have occurred during review process
-- the merge custodian will thank you.

The basic difference is making sure that the changes to our port work
before they go upstream. It would certainly be more frustrating to
wait for the daily merge to pick up your tweaks and find out that they
were wrong.

However, let's try to avoid situations where the change is stuck in
WebKit review limbo or abandoned, leaving forked files in our vendor
branch. I am not sure whether we need any special rules for these,
aside from the occasional stark glare from the merge people.

What do you think? Good rules, bad rules? Comments? Questions? Quirky
and entertaining remarks?

:DG<

--~--~-~--~~~---~--~~
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: Context menu for title bar doesn't appear when a tab's context menu was open

[Peter Kasting]

On Fri, Jan 9, 2009 at 6:13 AM, DeArto20  wrote:

> The following is the reply written by me on bugtracker - Issue 5695.


So... why are you mailing it to this list?

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] Context menu for title bar doesn't appear when a tab's context menu was open

[DeArto20]

The following is the reply written by me on bugtracker - Issue 5695.
http://crbug.com/5695

+++
I think chrome browser lacks consistency in displaying context menu.


* Current State
-
 context menu for the 'Tab' : Show up on right mouse button 'Release'
 context menu for the 'App' : Show up on right mouse button 'Press'
-

This inconsistent concept (one by 'Release' and the other by 'Press')
is not natural (in the UI point of view) and can cause problems.


Currently, when the right mouse button is 'Pressed' on the title bar,
its handler seems to take following two steps in order.

1. Close the current context menu if it exists.
2. Create new context menu.

Processing two operations (Closing and Creating) at one time ('Press')
can cause conflict problems.

- If the current context menu is for an 'App', there's no problem. But
   if it is for a 'Tab', it seems that above two steps come into the
   conflict and doesn't work well.


*Suggestion *

So, Divide two operations (Closing and Creating) into seperate
handlers.
- Closing always on 'Press' and Creating always on 'Release'.

If this concept is applied, no conflict can occur.
- When the  mouse button is 'Pressed', current (for a Tab or for an
App.)
  context menu is closed and when the button is 'Released', new
context
  menu is created.

And, it is natural that displaying context menu is always done by
'Release'
operation. (MS IE also uses this concept.)


* Suggested State:
-
 context menu for the 'Tab' : Show up on right mouse button 'Release'
 context menu for the 'App' : Show up on right mouse button 'Release'
-

+++

I wanna know your opinions about 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] Context menu for title bar doesn't appear when a tab's context menu was open

[DeArto20]

The following is my reply on the Issue 5695 in the bugtracker. (http://
crbug.com/5695)

++

I think chrome browser lacks consistency in displaying context menu.


* Current State

 context menu for the 'Tab' : Show up on right mouse button 'Release'
 context menu for the 'App' : Show up on right mouse button 'Press'


This inconsistent concept (one by 'Release' and the other by 'Press')
is not natural (in the UI point of view) and can cause problems.


Currently, when the right mouse button is 'Pressed' on the title bar,
its handler seems to take following two steps in order.

1. Close the current context menu if it exists.
2. Create new context menu.

Processing two operations (Closing and Creating) at one time ('Press')
can cause conflict problems.

- If the current context menu is for an 'App', there's no problem. But
   if it is for a 'Tab', it seems that above two steps come into the
   conflict and doesn't work well.


*Suggestion *

So, Divide two operations (Closing and Creating) into seperate
handlers.
- Closing always on 'Press' and Creating always on 'Release'.

If this concept is applied, no conflict can occur.
- When the  mouse button is 'Pressed', current (for a Tab or for an
App.)
  context menu is closed and when the button is 'Released', new
context
  menu is created.

And, it is natural that displaying context menu is always done by
'Release'
operation. (MS IE also uses this concept.)


* Suggested State:

 context menu for the 'Tab' : Show up on right mouse button 'Release'
 context menu for the 'App' : Show up on right mouse button 'Release'


++

I wanna know your opinions about this.


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---