[chromium-dev] 4.0 branch coming soon

[Mark Larson (Google)]

The feature freeze for 4.0 Stable is end of day today (Friday, 13 Nov). I've
had a few questions about branching, either from people who want to delay
committing crazy patches or people who want to make sure their feature lands
before we branch.

In a nutshell, we're going to branch Monday morning at 3 AM Pacific Standard
Time (GMT +8).

More details:

   - The next dev channel release is going to be the codebase we stabilize
   for 4.0. We'll first get it to Beta quality and then to Stable.
   - We don't announce specific dates for Google Chrome releases; we'll push
   Beta when things look pretty close and then move to Stable when the Beta
   channel shows solid quality.
   - We expect the next dev channel release to come from Monday's 3AM build,
   but if that is a really poor quality build, we'll try again with later code.
   If there are problems, the preferred course is still to branch and merge
   fixes on to the branch. We'll only delay branching if something really major
   is missing or broken.
   - Expect frequent Dev channel updates from the branch (instead of trunk)
   in the next few weeks. Right now it's more important for us to stabilize a
   release point than to get new code to the Dev channel. We want to rev the
   dev channel frequently to measure quality and Beta-worthiness on the 4.0
   branch.
   - We will fork/branch projects we depend on as needed. V8 already has a
   branch for 4.0
(1.3).
   We'll fork WebKit into chrome/trunk/branches/WebKit/250 (or whatever the
   build number turns out to be).
   - I or laforge@ will follow up next week (once we have a branch) with the
   rules of engagement for landing patches on the branch. The prime directives
   will be
  - "land on trunk or upstream first" (so we get the benefit of better
  code review and automated test coverage), but there will be a few cases
  where we need to create special patches for the branch.
  - patches must fix an Mstone-4 bug.

Fire away with your questions,
Mark

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

Re: [chromium-dev] How to compile Google Chrome with Visual C++ 2008 Express Edition

[PhistucK]

Can this be ported to the 2005 version also? I would like to try and make it
work on 2005 Express.

☆PhistucK


On Fri, Nov 13, 2009 at 02:51, Bradley Nelson  wrote:

> Ok that fix is in.
> You'd need to set GYP_MSVS_VERSION=2008e
>
> Let me know how that goes for you.
>
> -BradN
>
>
> On Wed, Nov 11, 2009 at 12:50 PM, Marc-Antoine Ruel 
> wrote:
>
>> Updated
>> http://sites.google.com/a/chromium.org/dev/developers/how-tos/build-instructions-windows
>> to reference your blog entry.
>>
>> I don't want to copy these instructions since it's too lengthy,
>> inefficient and unsupported.
>>
>> I didn't realize one could download WDK 7 without needing a MSDN
>> account. That's cool.
>>
>> M-A
>>
>> On Tue, Nov 10, 2009 at 10:39 PM, Dominic Jodoin
>>  wrote:
>> > On Tue, Nov 10, 2009 at 10:25 PM, Peter Kasting 
>> wrote:
>> >>
>> >> What do you mean?  Or to be more precise, what would considering your
>> steps
>> >> "a valid setup to contribute" concretely result in?
>> >> PK
>> >
>> > I'm wondering if using a hacked ATL version 7.1 could lead to bugs
>> > given the product is built, I suppose, with ATL coming with Visual
>> > Studio 2005 or 2008 which is a different version.
>> >
>> > But what I meant was that if the steps were to be approved, I thought
>> > they could be included on http://dev.chromium.org.
>> >
>> > -- Dominic.
>> >
>> > --
>> > Chromium Developers mailing list: chromium-dev@googlegroups.com
>> > View archives, change email options, or unsubscribe:
>> >http://groups.google.com/group/chromium-dev
>> >
>>
>> --
>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> View archives, change email options, or unsubscribe:
>>http://groups.google.com/group/chromium-dev
>>
>
>  --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-dev
>

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

Re: [chromium-dev] How to compile Google Chrome with Visual C++ 2008 Express Edition

[PhistucK]

Looking at the actual patch, I see there is (an apparent) support for 2005e,
as well.

Sorry and thank you.

☆PhistucK


On Fri, Nov 13, 2009 at 02:51, Bradley Nelson  wrote:

> Ok that fix is in.
> You'd need to set GYP_MSVS_VERSION=2008e
>
> Let me know how that goes for you.
>
> -BradN
>
>
> On Wed, Nov 11, 2009 at 12:50 PM, Marc-Antoine Ruel 
> wrote:
>
>> Updated
>> http://sites.google.com/a/chromium.org/dev/developers/how-tos/build-instructions-windows
>> to reference your blog entry.
>>
>> I don't want to copy these instructions since it's too lengthy,
>> inefficient and unsupported.
>>
>> I didn't realize one could download WDK 7 without needing a MSDN
>> account. That's cool.
>>
>> M-A
>>
>> On Tue, Nov 10, 2009 at 10:39 PM, Dominic Jodoin
>>  wrote:
>> > On Tue, Nov 10, 2009 at 10:25 PM, Peter Kasting 
>> wrote:
>> >>
>> >> What do you mean?  Or to be more precise, what would considering your
>> steps
>> >> "a valid setup to contribute" concretely result in?
>> >> PK
>> >
>> > I'm wondering if using a hacked ATL version 7.1 could lead to bugs
>> > given the product is built, I suppose, with ATL coming with Visual
>> > Studio 2005 or 2008 which is a different version.
>> >
>> > But what I meant was that if the steps were to be approved, I thought
>> > they could be included on http://dev.chromium.org.
>> >
>> > -- Dominic.
>> >
>> > --
>> > Chromium Developers mailing list: chromium-dev@googlegroups.com
>> > View archives, change email options, or unsubscribe:
>> >http://groups.google.com/group/chromium-dev
>> >
>>
>> --
>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> View archives, change email options, or unsubscribe:
>>http://groups.google.com/group/chromium-dev
>>
>
>  --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-dev
>

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

[chromium-dev] Problem during compilation about gen_x86_insn.py

[sahid]

Hello,

sa...@sahid-work:~/Documents/chromium/src$ cat /etc/debian_version
squeeze/sid

sa...@sahid-work:~/Documents/chromium/src$ uname -sra
Linux sahid-work 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:04:26
UTC 2009 i686 GNU/Linux

sa...@sahid-work:~/Documents/chromium/src$ svn info
Path: .
URL: http://src.chromium.org/svn/trunk/src
Repository Root: http://src.chromium.org/svn
Repository UUID: 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Revision: 31896
Node Kind: directory
Schedule: normal
Last Changed Author: phajdan...@chromium.org
Last Changed Rev: 31896
Last Changed Date: 2009-11-13 10:17:58 +0100 (Fri, 13 Nov 2009)


i have this error:

  CXX(target) out/Debug/obj.target/wtf/third_party/WebKit/
JavaScriptCore/wtf/unicode/UTF8.o
  LINK(target) out/Debug/genperf
make: *** No rule to make target `third_party/yasm/source/patched-yasm/
modules/arch/x86/gen_x86_insn.py', needed by `out/Debug/obj/gen/
third_party/yasm/x86insns.c'.  Stop.
make: *** Waiting for unfinished jobs
  LINK(target) out/Debug/genversion
g++: out/Debug/obj.target/genversion/third_party/yasm/source/patched-
yasm/modules/preprocs/nasm/genversion.o: No such file or directory
make: *** [out/Debug/genversion] Error 1


you have an idea ??

thank you

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

Re: [chromium-dev] Problem during compilation about gen_x86_insn.py

[Lei Zhang]

Do you have 
src/third_party/yasm/source/patched-yasm/modules/arch//x86/gen_x86_insn.py
checked out?

On Fri, Nov 13, 2009 at 1:43 AM, sahid  wrote:
> Hello,
>
> sa...@sahid-work:~/Documents/chromium/src$ cat /etc/debian_version
> squeeze/sid
>
> sa...@sahid-work:~/Documents/chromium/src$ uname -sra
> Linux sahid-work 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:04:26
> UTC 2009 i686 GNU/Linux
>
> sa...@sahid-work:~/Documents/chromium/src$ svn info
> Path: .
> URL: http://src.chromium.org/svn/trunk/src
> Repository Root: http://src.chromium.org/svn
> Repository UUID: 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
> Revision: 31896
> Node Kind: directory
> Schedule: normal
> Last Changed Author: phajdan...@chromium.org
> Last Changed Rev: 31896
> Last Changed Date: 2009-11-13 10:17:58 +0100 (Fri, 13 Nov 2009)
>
>
> i have this error:
>
>  CXX(target) out/Debug/obj.target/wtf/third_party/WebKit/
> JavaScriptCore/wtf/unicode/UTF8.o
>  LINK(target) out/Debug/genperf
> make: *** No rule to make target `third_party/yasm/source/patched-yasm/
> modules/arch/x86/gen_x86_insn.py', needed by `out/Debug/obj/gen/
> third_party/yasm/x86insns.c'.  Stop.
> make: *** Waiting for unfinished jobs
>  LINK(target) out/Debug/genversion
> g++: out/Debug/obj.target/genversion/third_party/yasm/source/patched-
> yasm/modules/preprocs/nasm/genversion.o: No such file or directory
> make: *** [out/Debug/genversion] Error 1
>
>
> you have an idea ??
>
> thank you
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>    http://groups.google.com/group/chromium-dev
>

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

Re: [chromium-dev] Problem during compilation about gen_x86_insn.py

[Adam Langley]

On Fri, Nov 13, 2009 at 1:43 AM, sahid  wrote:
> make: *** No rule to make target `third_party/yasm/source/patched-yasm/
> modules/arch/x86/gen_x86_insn.py', needed by `out/Debug/obj/gen/

This file should exist. If it doesn't, your checkout is incomplete.

Make sure that you're running `gclient sync` after updating the main
SVN repo. If that doesn't solve the issue you probably need to do a
new, clean checkout.



AGL

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

[chromium-dev] Getting 'This is a read-only checkout' error from gcl

[Jens Alfke]

A few days ago I started getting an error when using gcl to create  
changelists in my WebKit tree:

$ pwd
/Volumes/Yttrium/src/third_party/WebKit
$ gcl change foo
This is a read-only checkout.  Retry in a read-write checkout or use -- 
force to override.

I don't get the error if I use gcl in the top-level Chromium directory.

I recently upgraded my Mac's svn from the stock 1.4.4 to 1.6.6; but  
this doesn't explain why gcl would work in one repo but not in another.

Any idea? AFAIK I need to use gcl to be able to submit WebKit patches  
to the try bots...

—Jens

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

[chromium-dev] Any interest in command line tools for network stack?

[Chris Bentzel]

Howdy,

I've been trying to dive into the Chromium codebase and have been
focusing on the network stack after getting the gist of how Chromium
on the whole is organized.

I've written a few hacky little command line tools to exercise some of
the networking components (nslookup-like for HostResolver, wget-like
for HttpNetworkTransaction). Should I spend time trying to flesh these
out and add to net/tools, or is this something which doesn't belong in
the chromium codebase?

Thanks,
Chris

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

Re: [chromium-dev] Getting 'This is a read-only checkout' error from gcl

[Dirk Pranke]

I started getting this on my mac at home, and haven't taken the time
to track it down yet. Is it possible your environment got switched
from the svn:// checkout to an https:// read-only checkout?

-- Dirk

On Fri, Nov 13, 2009 at 10:41 AM, Jens Alfke  wrote:
> A few days ago I started getting an error when using gcl to create
> changelists in my WebKit tree:
>
> $ pwd
> /Volumes/Yttrium/src/third_party/WebKit
> $ gcl change foo
> This is a read-only checkout.  Retry in a read-write checkout or use --
> force to override.
>
> I don't get the error if I use gcl in the top-level Chromium directory.
>
> I recently upgraded my Mac's svn from the stock 1.4.4 to 1.6.6; but
> this doesn't explain why gcl would work in one repo but not in another.
>
> Any idea? AFAIK I need to use gcl to be able to submit WebKit patches
> to the try bots...
>
> —Jens
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>    http://groups.google.com/group/chromium-dev
>

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

Re: [chromium-dev] Any interest in command line tools for network stack?

[Jeremy Orlow]

What's the intended purpose of such tools?  Do they offer any functionality
beyond the standard tools?  Do you envision them being helpful to people
debugging the Chromium network stack?

(Me replying does in no way imply that I have the authority to say yes or
no, btw.  :-)

On Fri, Nov 13, 2009 at 11:13 AM, Chris Bentzel  wrote:

> Howdy,
>
> I've been trying to dive into the Chromium codebase and have been
> focusing on the network stack after getting the gist of how Chromium
> on the whole is organized.
>
> I've written a few hacky little command line tools to exercise some of
> the networking components (nslookup-like for HostResolver, wget-like
> for HttpNetworkTransaction). Should I spend time trying to flesh these
> out and add to net/tools, or is this something which doesn't belong in
> the chromium codebase?
>
> Thanks,
> Chris
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>

-- 
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: [chromium-extensions] openDatabase() maximum size

[Antony Sargent]

[+chromium-dev and dumi]

I'm not sure what our overall plan is with respect to quotas for html5
databases, and whether we've discussed giving extensions larger quotas than
regular web content. Dumi or anyone else care to comment?


On Thu, Nov 12, 2009 at 10:39 PM, Yuichi Tateno wrote:

> Hi,
>
> I am experiencing some issues specifying the maximum size with
> estimatedSize in openDatabase.
> Regardless of whatever value I specify it as, approximately 5MB seems
> to be the maximum size.
>
> http://dev.w3.org/html5/webdatabase/#databases
>
> Because the extension that I am developing is used to synchronize data
> from a social bookmarking site, the 5MB size is not enough and I am
> having some trouble.
>
> In the future could you please see that estimatedSize can be specified
> properly, or do you have a plan to increase the size limit to higher
> than 5MB?
>
> 
> Yuichi Tateno
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Chromium-extensions" group.
> To post to this group, send email to chromium-extensi...@googlegroups.com.
> To unsubscribe from this group, send email to
> chromium-extensions+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/chromium-extensions?hl=.
>
>
>

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

Re: [chromium-dev] Any interest in command line tools for network stack?

[Chris Bentzel]

I'm using them as a learning exercise for the network stack - and I'm
guessing that they will help debug behavior in the future as well.

I don't intend to add additional functionality over the standard tools
- in fact, I promise you they'll be less functional than the standard
tools. For example, my hresolv executable just takes a hostname and a
port as options for now.

I'll spend a bit more time getting them to a reasonable point and send
a patch out for review - figure decision will be easier then over a
vague description.

Thanks,
Chris

On Fri, Nov 13, 2009 at 2:49 PM, Jeremy Orlow  wrote:
> What's the intended purpose of such tools?  Do they offer any functionality
> beyond the standard tools?  Do you envision them being helpful to people
> debugging the Chromium network stack?
> (Me replying does in no way imply that I have the authority to say yes or
> no, btw.  :-)
>
> On Fri, Nov 13, 2009 at 11:13 AM, Chris Bentzel  wrote:
>>
>> Howdy,
>>
>> I've been trying to dive into the Chromium codebase and have been
>> focusing on the network stack after getting the gist of how Chromium
>> on the whole is organized.
>>
>> I've written a few hacky little command line tools to exercise some of
>> the networking components (nslookup-like for HostResolver, wget-like
>> for HttpNetworkTransaction). Should I spend time trying to flesh these
>> out and add to net/tools, or is this something which doesn't belong in
>> the chromium codebase?
>>
>> Thanks,
>> Chris
>>
>> --
>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> View archives, change email options, or unsubscribe:
>>    http://groups.google.com/group/chromium-dev
>
>

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

Re: [chromium-dev] Any interest in command line tools for network stack?

[Dan Kegel]

I like the idea.

On Fri, Nov 13, 2009 at 11:58 AM, Chris Bentzel  wrote:
> I'm using them as a learning exercise for the network stack - and I'm
> guessing that they will help debug behavior in the future as well.
>
> I don't intend to add additional functionality over the standard tools
> - in fact, I promise you they'll be less functional than the standard
> tools. For example, my hresolv executable just takes a hostname and a
> port as options for now.
>
> I'll spend a bit more time getting them to a reasonable point and send
> a patch out for review - figure decision will be easier then over a
> vague description.
>
> Thanks,
> Chris
>
> On Fri, Nov 13, 2009 at 2:49 PM, Jeremy Orlow  wrote:
>> What's the intended purpose of such tools?  Do they offer any functionality
>> beyond the standard tools?  Do you envision them being helpful to people
>> debugging the Chromium network stack?
>> (Me replying does in no way imply that I have the authority to say yes or
>> no, btw.  :-)
>>
>> On Fri, Nov 13, 2009 at 11:13 AM, Chris Bentzel  wrote:
>>>
>>> Howdy,
>>>
>>> I've been trying to dive into the Chromium codebase and have been
>>> focusing on the network stack after getting the gist of how Chromium
>>> on the whole is organized.
>>>
>>> I've written a few hacky little command line tools to exercise some of
>>> the networking components (nslookup-like for HostResolver, wget-like
>>> for HttpNetworkTransaction). Should I spend time trying to flesh these
>>> out and add to net/tools, or is this something which doesn't belong in
>>> the chromium codebase?
>>>
>>> Thanks,
>>> Chris
>>>
>>> --
>>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>>> View archives, change email options, or unsubscribe:
>>>    http://groups.google.com/group/chromium-dev
>>
>>
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>    http://groups.google.com/group/chromium-dev

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

Re: [chromium-dev] Any interest in command line tools for network stack?

[Peter Kasting]

On Fri, Nov 13, 2009 at 11:13 AM, Chris Bentzel  wrote:

> Should I spend time trying to flesh these
> out and add to net/tools, or is this something which doesn't belong in
> the chromium codebase?


I'm weakly against the idea, since adding dependencies increases the burden
when we want to redesign or update pieces of the network stack.  I would
change my vote to be in favor if these tools allowed some kind of testing of
the stack that is not currently feasible; better testing is always a good
goal.

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] More sheriffs?

[Peter Kasting]

At lunch today, a few of us discussed the idea of moving from two sheriffs
to four.

There are several reasons we contemplated such a change:
* The team is large enough that on the current schedule, you go months
between sheriffing, which is so long that you forget things like what tools
help you do what.
* Sheriffing is a heavy burden, and getting moreso with more team members.
* Either the two sheriffs are in different time zones, in which case you
have effectively one sheriff on duty who has to do everything (bad due to
point above), or they're not, in which case a chunk of the day is not
covered at all.
* New sheriffs could really use a "mentor sheriff" with them, which is
pretty difficult to schedule.

I think these are good reasons, so I propose we make this change.  Comments?

PK

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

Re: [chromium-dev] More sheriffs?

[Peter Kasting]

On Fri, Nov 13, 2009 at 12:35 PM, Ben Goodger  wrote:

> On Fri, Nov 13, 2009 at 12:31 PM, Peter Kasting 
> wrote:
> > * The team is large enough that on the current schedule, you go months
> > between sheriffing, which is so long that you forget things like what
> tools
> > help you do what.
>
> This info should be written down and kept up to date by sheriffs on a
> daily basis.


See http://dev.chromium.org/developers/tree-sheriffs , which is linked off
our main developer wiki page.

PK

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

Re: [chromium-dev] Any interest in command line tools for network stack?

[Dan Kegel]

On Fri, Nov 13, 2009 at 12:25 PM, Peter Kasting  wrote:
>> Should I spend time trying to flesh these
>> out and add to net/tools, or is this something which doesn't belong in
>> the chromium codebase?
>
> I'm weakly against the idea, since adding dependencies increases the burden
> when we want to redesign or update pieces of the network stack.  I would
> change my vote to be in favor if these tools allowed some kind of testing of
> the stack that is not currently feasible; better testing is always a good
> goal.

I think it would be valuable to have a netcat-like thing implemented
using chromium's stack because it would make certain kinds of
testing and debugging easier.  (In particular, I'm looking at a hang
in the ssl tests that only happens in one strange environment, and
having a standalone app that just makes an ssl connection using
chromium's stack would be quite handy.)

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

Re: [chromium-dev] More sheriffs?

[Peter Kasting]

On Fri, Nov 13, 2009 at 12:44 PM, Stuart Morgan wrote:

> If we end up actually having four at a time that seems likely to be
> worse than two: either four people are doing nothing but sheriffing,
> which there is probably not enough work for, or all four people are
> more likely to think that someone else is probably watching and they
> can do something else.


I can only say that in my own sheriffing experience that this is utterly
untrue, and having two people at once is amazingly helpful since we can
track down different problem areas; one working on purify and valgrind
errors while another works on layout tests.  There has never been a time in
such cases where we both did nothing because we thought the other person was
working on it; we were always pinging each other and dividing work on the
fly.

I don't think Chromium team members are so irresponsible that they would not
work out some system in such cases.  And part of the point is that it would
be nice to be able to get a _little_ bit of work done on the days you're
sheriffing, or go to lunch, or whatever.

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: [chromium-extensions] openDatabase() maximum size

[Dumitru Daniliuc]

estimatedSize is useless. neither chromium nor safari really uses it (we
save it "in case we might wanna do something with it in the future", but
that's about it).

in chromium, we currently have a hard limit of 5MB per origin. it's pretty
easy to write code that would allow users/extensions to increase it, but the
big issue is that we don't know yet how we want to manage quotas (per origin
DB quota? per origin quota for DBs + local storage + app cache?
per-something else quotas? and what's the best way to change/increase it and
not allow malicious apps to fill up the hard drive at the same time?). i
think we're really close to tackling these issues and should have a quota
management system in place soon.

dumi


On Fri, Nov 13, 2009 at 12:01 PM, Antony Sargent wrote:

> [+chromium-dev and dumi]
>
> I'm not sure what our overall plan is with respect to quotas for html5
> databases, and whether we've discussed giving extensions larger quotas than
> regular web content. Dumi or anyone else care to comment?
>
>
> On Thu, Nov 12, 2009 at 10:39 PM, Yuichi Tateno wrote:
>
>> Hi,
>>
>> I am experiencing some issues specifying the maximum size with
>> estimatedSize in openDatabase.
>> Regardless of whatever value I specify it as, approximately 5MB seems
>> to be the maximum size.
>>
>> http://dev.w3.org/html5/webdatabase/#databases
>>
>> Because the extension that I am developing is used to synchronize data
>> from a social bookmarking site, the 5MB size is not enough and I am
>> having some trouble.
>>
>> In the future could you please see that estimatedSize can be specified
>> properly, or do you have a plan to increase the size limit to higher
>> than 5MB?
>>
>> 
>> Yuichi Tateno
>>
>> --
>>
>> You received this message because you are subscribed to the Google Groups
>> "Chromium-extensions" group.
>> To post to this group, send email to chromium-extensi...@googlegroups.com
>> .
>> To unsubscribe from this group, send email to
>> chromium-extensions+unsubscr...@googlegroups.com
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/chromium-extensions?hl=.
>>
>>
>>
>

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

Re: [chromium-dev] Getting 'This is a read-only checkout' error from gcl

[Dominic Mazzoni]

I got the same error yesterday.  Note that I don't have write access,
so it's true that I do have a read-only checkout, but before, there
was no warning just to create, upload or try.  Now I have to use
--force in order to do any of those operations.

- Dominic

On Fri, Nov 13, 2009 at 11:49 AM, Dirk Pranke  wrote:
> I started getting this on my mac at home, and haven't taken the time
> to track it down yet. Is it possible your environment got switched
> from the svn:// checkout to an https:// read-only checkout?
>
> -- Dirk
>
> On Fri, Nov 13, 2009 at 10:41 AM, Jens Alfke  wrote:
>> A few days ago I started getting an error when using gcl to create
>> changelists in my WebKit tree:
>>
>> $ pwd
>> /Volumes/Yttrium/src/third_party/WebKit
>> $ gcl change foo
>> This is a read-only checkout.  Retry in a read-write checkout or use --
>> force to override.
>>
>> I don't get the error if I use gcl in the top-level Chromium directory.
>>
>> I recently upgraded my Mac's svn from the stock 1.4.4 to 1.6.6; but
>> this doesn't explain why gcl would work in one repo but not in another.
>>
>> Any idea? AFAIK I need to use gcl to be able to submit WebKit patches
>> to the try bots...
>>
>> —Jens
>>
>> --
>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> View archives, change email options, or unsubscribe:
>>    http://groups.google.com/group/chromium-dev
>>
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>    http://groups.google.com/group/chromium-dev
>

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

Re: [chromium-dev] More sheriffs?

[Jeremy Orlow]

For a while now, I've advocated having 2 pacific timezone sheriffs always on
duty and having one or two in other time zones.  I still advocate such an
idea.

So, to be clear, I think this is a good idea as long as the distribution of
sheriffs (time zone wise) is deliberate.

(I think this addresses Stuart's concern as well.)

J

On Fri, Nov 13, 2009 at 12:31 PM, Peter Kasting  wrote:

> At lunch today, a few of us discussed the idea of moving from two sheriffs
> to four.
>
> There are several reasons we contemplated such a change:
> * The team is large enough that on the current schedule, you go months
> between sheriffing, which is so long that you forget things like what tools
> help you do what.
> * Sheriffing is a heavy burden, and getting moreso with more team members.
> * Either the two sheriffs are in different time zones, in which case you
> have effectively one sheriff on duty who has to do everything (bad due to
> point above), or they're not, in which case a chunk of the day is not
> covered at all.
> * New sheriffs could really use a "mentor sheriff" with them, which is
> pretty difficult to schedule.
>
> I think these are good reasons, so I propose we make this change.
>  Comments?
>
> PK
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-dev
>

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

Re: [chromium-dev] More sheriffs?

[Andrew Scherkus]

(resending to chromium-dev)

Sheriffing the PST time zone is usually the worst.  We could experiment with
tweaking the scheduling algorithm to have two PST sheriffs and one non-PST
sheriff per shift.

Other than that -- fixing flaky tests would go a long way to making the job
easier.  Right now out of 12 failing bots, only 1 is a true failure.

On Fri, Nov 13, 2009 at 12:48 PM, Peter Kasting  wrote:

> On Fri, Nov 13, 2009 at 12:44 PM, Stuart Morgan 
> wrote:
>
>> If we end up actually having four at a time that seems likely to be
>> worse than two: either four people are doing nothing but sheriffing,
>> which there is probably not enough work for, or all four people are
>> more likely to think that someone else is probably watching and they
>> can do something else.
>
>
> I can only say that in my own sheriffing experience that this is utterly
> untrue, and having two people at once is amazingly helpful since we can
> track down different problem areas; one working on purify and valgrind
> errors while another works on layout tests.  There has never been a time in
> such cases where we both did nothing because we thought the other person was
> working on it; we were always pinging each other and dividing work on the
> fly.
>
> I don't think Chromium team members are so irresponsible that they would
> not work out some system in such cases.  And part of the point is that it
> would be nice to be able to get a _little_ bit of work done on the days
> you're sheriffing, or go to lunch, or whatever.
>
> PK
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-dev
>

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

Re: [chromium-dev] Re: [chromium-extensions] openDatabase() maximum size

[Aaron Boodman]

My name is Aaron Boodman and I support the motion to give extensions
extra space.

On Fri, Nov 13, 2009 at 12:01 PM, Antony Sargent  wrote:
> [+chromium-dev and dumi]
> I'm not sure what our overall plan is with respect to quotas for html5
> databases, and whether we've discussed giving extensions larger quotas than
> regular web content. Dumi or anyone else care to comment?
>
> On Thu, Nov 12, 2009 at 10:39 PM, Yuichi Tateno 
> wrote:
>>
>> Hi,
>>
>> I am experiencing some issues specifying the maximum size with
>> estimatedSize in openDatabase.
>> Regardless of whatever value I specify it as, approximately 5MB seems
>> to be the maximum size.
>>
>> http://dev.w3.org/html5/webdatabase/#databases
>>
>> Because the extension that I am developing is used to synchronize data
>> from a social bookmarking site, the 5MB size is not enough and I am
>> having some trouble.
>>
>> In the future could you please see that estimatedSize can be specified
>> properly, or do you have a plan to increase the size limit to higher
>> than 5MB?
>>
>> 
>> Yuichi Tateno
>>
>> --
>>
>> You received this message because you are subscribed to the Google Groups
>> "Chromium-extensions" group.
>> To post to this group, send email to chromium-extensi...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> chromium-extensions+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/chromium-extensions?hl=.
>>
>>
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-dev

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

Re: [chromium-dev] Re: [chromium-extensions] openDatabase() maximum size

[Jeremy Orlow]

Just for the record, you're also the one who originally said it was fine to
limit them to 5mb (for LocalStorage anyhow).  :-)

What kind of extra space did you have in mind?  Unlimited?

It's pretty late in the game to be making a decision like this for mstone-4,
but it might be possible if this was considered a major issue.

J

On Fri, Nov 13, 2009 at 1:03 PM, Aaron Boodman  wrote:

> My name is Aaron Boodman and I support the motion to give extensions
> extra space.
>
> On Fri, Nov 13, 2009 at 12:01 PM, Antony Sargent 
> wrote:
> > [+chromium-dev and dumi]
> > I'm not sure what our overall plan is with respect to quotas for html5
> > databases, and whether we've discussed giving extensions larger quotas
> than
> > regular web content. Dumi or anyone else care to comment?
> >
> > On Thu, Nov 12, 2009 at 10:39 PM, Yuichi Tateno 
> > wrote:
> >>
> >> Hi,
> >>
> >> I am experiencing some issues specifying the maximum size with
> >> estimatedSize in openDatabase.
> >> Regardless of whatever value I specify it as, approximately 5MB seems
> >> to be the maximum size.
> >>
> >> http://dev.w3.org/html5/webdatabase/#databases
> >>
> >> Because the extension that I am developing is used to synchronize data
> >> from a social bookmarking site, the 5MB size is not enough and I am
> >> having some trouble.
> >>
> >> In the future could you please see that estimatedSize can be specified
> >> properly, or do you have a plan to increase the size limit to higher
> >> than 5MB?
> >>
> >> 
> >> Yuichi Tateno
> >>
> >> --
> >>
> >> You received this message because you are subscribed to the Google
> Groups
> >> "Chromium-extensions" group.
> >> To post to this group, send email to
> chromium-extensi...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> chromium-extensions+unsubscr...@googlegroups.com
> .
> >> For more options, visit this group at
> >> http://groups.google.com/group/chromium-extensions?hl=.
> >>
> >>
> >
> > --
> > Chromium Developers mailing list: chromium-dev@googlegroups.com
> > View archives, change email options, or unsubscribe:
> > http://groups.google.com/group/chromium-dev
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Chromium-extensions" group.
> To post to this group, send email to chromium-extensi...@googlegroups.com.
> To unsubscribe from this group, send email to
> chromium-extensions+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/chromium-extensions?hl=.
>
>
>

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

Re: [chromium-dev] Getting 'This is a read-only checkout' error from gcl

[Marc-Antoine Ruel]

Fixed,

http://src.chromium.org/viewvc/chrome?view=rev&revision=31942

On Fri, Nov 13, 2009 at 3:51 PM, Dominic Mazzoni  wrote:
> I got the same error yesterday.  Note that I don't have write access,
> so it's true that I do have a read-only checkout, but before, there
> was no warning just to create, upload or try.  Now I have to use
> --force in order to do any of those operations.
>
> - Dominic
>
> On Fri, Nov 13, 2009 at 11:49 AM, Dirk Pranke  wrote:
>> I started getting this on my mac at home, and haven't taken the time
>> to track it down yet. Is it possible your environment got switched
>> from the svn:// checkout to an https:// read-only checkout?
>>
>> -- Dirk
>>
>> On Fri, Nov 13, 2009 at 10:41 AM, Jens Alfke  wrote:
>>> A few days ago I started getting an error when using gcl to create
>>> changelists in my WebKit tree:
>>>
>>> $ pwd
>>> /Volumes/Yttrium/src/third_party/WebKit
>>> $ gcl change foo
>>> This is a read-only checkout.  Retry in a read-write checkout or use --
>>> force to override.
>>>
>>> I don't get the error if I use gcl in the top-level Chromium directory.
>>>
>>> I recently upgraded my Mac's svn from the stock 1.4.4 to 1.6.6; but
>>> this doesn't explain why gcl would work in one repo but not in another.
>>>
>>> Any idea? AFAIK I need to use gcl to be able to submit WebKit patches
>>> to the try bots...
>>>
>>> —Jens
>>>
>>> --
>>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>>> View archives, change email options, or unsubscribe:
>>>    http://groups.google.com/group/chromium-dev
>>>
>>
>> --
>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> View archives, change email options, or unsubscribe:
>>    http://groups.google.com/group/chromium-dev
>>
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>    http://groups.google.com/group/chromium-dev
>

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

Re: [chromium-dev] Getting 'This is a read-only checkout' error from gcl

[Dominic Mazzoni]

Works great now.  Thanks for the quick patch!  Sorry I didn't mention
it earlier, I thought I was doing something wrong...

- Dominic

On Fri, Nov 13, 2009 at 1:11 PM, Marc-Antoine Ruel  wrote:
> Fixed,
>
> http://src.chromium.org/viewvc/chrome?view=rev&revision=31942
>
> On Fri, Nov 13, 2009 at 3:51 PM, Dominic Mazzoni  wrote:
>> I got the same error yesterday.  Note that I don't have write access,
>> so it's true that I do have a read-only checkout, but before, there
>> was no warning just to create, upload or try.  Now I have to use
>> --force in order to do any of those operations.
>>
>> - Dominic
>>
>> On Fri, Nov 13, 2009 at 11:49 AM, Dirk Pranke  wrote:
>>> I started getting this on my mac at home, and haven't taken the time
>>> to track it down yet. Is it possible your environment got switched
>>> from the svn:// checkout to an https:// read-only checkout?
>>>
>>> -- Dirk
>>>
>>> On Fri, Nov 13, 2009 at 10:41 AM, Jens Alfke  wrote:
 A few days ago I started getting an error when using gcl to create
 changelists in my WebKit tree:

 $ pwd
 /Volumes/Yttrium/src/third_party/WebKit
 $ gcl change foo
 This is a read-only checkout.  Retry in a read-write checkout or use --
 force to override.

 I don't get the error if I use gcl in the top-level Chromium directory.

 I recently upgraded my Mac's svn from the stock 1.4.4 to 1.6.6; but
 this doesn't explain why gcl would work in one repo but not in another.

 Any idea? AFAIK I need to use gcl to be able to submit WebKit patches
 to the try bots...

 —Jens

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

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

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

Re: [chromium-dev] Re: [chromium-extensions] openDatabase() maximum size

[Aaron Boodman]

On Fri, Nov 13, 2009 at 1:07 PM, Jeremy Orlow  wrote:
> Just for the record, you're also the one who originally said it was fine to
> limit them to 5mb (for LocalStorage anyhow).  :-)

It is a consistent position to say "it is fine to limit it to 5mb for
now" and also say "it would be nice to allow additional space
someday". :)

> What kind of extra space did you have in mind?  Unlimited?
> It's pretty late in the game to be making a decision like this for mstone-4,
> but it might be possible if this was considered a major issue.

Sorry, I didn't mean it for mstone 4, that is impossible. I'm just
saying in general, that I think it would be cool for extensions to be
able to request additional space. I await seeing what you guys come up
with for quota management for the web platform.

- a

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

Re: [chromium-dev] More sheriffs?

[Peter Kasting]

On Fri, Nov 13, 2009 at 1:15 PM, Finnur Thorarinsson wrote:

> If the sheriff load is too much for two people to devote 100% of their time
> to, then there is something wrong with the process.
>

It's clearly too much, given that I hardly see any other sheriffs even
attempt to maintain the rule of "every bot green all the time", which is
what you're supposed to do as sheriff.  And when I maintain it, I need to
keep the tree closed for long periods while I deal with the myriad of issues
that come up.

Solving the problem by having the tree open if things "aren't too bad" is
not good enough.  Right now I just checked and the purify and valgrind bots
were red.  As usual.  No sign of anyone looking into them.

Sheriffs are in theory supposed to watch all the perf bots too.  Do you?  I
don't.  I doubt very many people do.  There is tons of information available
to sheriffs and too few people to cover it.  Someone watching perf, someone
watching purify/valgrind, someone watching layout tests, and someone
watching everything else would be really helpful.  Especially if one of
those people was experienced enough to help somebody else doing it for the
first time.  The team is growing fast enough that we have a _lot_ of
first-time sheriffs.

PK

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

Re: [chromium-dev] Re: [chromium-extensions] openDatabase() maximum size

[Jeremy Orlow]

On Fri, Nov 13, 2009 at 1:21 PM, Aaron Boodman  wrote:

> On Fri, Nov 13, 2009 at 1:07 PM, Jeremy Orlow  wrote:
> > Just for the record, you're also the one who originally said it was fine
> to
> > limit them to 5mb (for LocalStorage anyhow).  :-)
>
> It is a consistent position to say "it is fine to limit it to 5mb for
> now" and also say "it would be nice to allow additional space
> someday". :)
>
> > What kind of extra space did you have in mind?  Unlimited?
> > It's pretty late in the game to be making a decision like this for
> mstone-4,
> > but it might be possible if this was considered a major issue.
>
> Sorry, I didn't mean it for mstone 4, that is impossible. I'm just
> saying in general, that I think it would be cool for extensions to be
> able to request additional space. I await seeing what you guys come up
> with for quota management for the web platform.
>

I think the plan for the web platform (for now anyhow) is that if you want
more quota you need to install an extension.

Are we OK with giving extensions unlimited storage space?  It seems like
doing so would be reasonable as long as we gave the user the option to clean
up the disk space when the extension is uninstalled.

Either way, let's target something better (at least for extensions) for
mstone 5.

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

Re: [chromium-dev] More sheriffs?

[Lei Zhang]

Big +1 for at least a third sheriff.

With two sheriffs, if one is not in PST, then really we only have one
sheriff. If that sheriff happens to be new, then we have 0 <=
num_sheriffs <= 1.

On Fri, Nov 13, 2009 at 12:31 PM, Peter Kasting  wrote:
> At lunch today, a few of us discussed the idea of moving from two sheriffs
> to four.
> There are several reasons we contemplated such a change:
> * The team is large enough that on the current schedule, you go months
> between sheriffing, which is so long that you forget things like what tools
> help you do what.
> * Sheriffing is a heavy burden, and getting moreso with more team members.
> * Either the two sheriffs are in different time zones, in which case you
> have effectively one sheriff on duty who has to do everything (bad due to
> point above), or they're not, in which case a chunk of the day is not
> covered at all.
> * New sheriffs could really use a "mentor sheriff" with them, which is
> pretty difficult to schedule.
> I think these are good reasons, so I propose we make this change.  Comments?
> PK
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-dev

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

Re: [chromium-dev] More sheriffs?

[Peter Kasting]

On Fri, Nov 13, 2009 at 1:33 PM, Stuart Morgan wrote:

> On Fri, Nov 13, 2009 at 1:25 PM, Peter Kasting 
> wrote:
> > Sheriffs are in theory supposed to watch all the perf bots too.  Do you?
>  I
> > don't.  I doubt very many people do.
>
> That's probably mostly a function of the fact that there's essentially
> no mention of monitoring perf (the fact that they should, how to do
> it, how to handle regressions, etc.) on the page about what sheriffs
> should do, not a manpower issue.


Given that our project lead didn't even know there _was_ such a page, I'm
not convinced.  I don't think most sheriffs exhaustively read and understand
that page, and the tasks and best practices as sheriff change rapidly (I
hadn't ever heard of "drover" last time I sheriffed), which is part of the
motivation for speeding up the cycle.

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: More sheriffs?

[Peter Kasting]

It sounds like so far there is more support for the idea of three sheriffs
than four.  What if I modify the proposal to be:

* Change from two sheriffs to three
* Try to ensure that one of those three is non-PST if this is possible
without overloading teams outside MTV (this will probably get more and more
feasible as we continue to build staff in Tokyo, London, etc.)
* Try to ensure that at least one of those three has been a sheriff before
* Link to the sheriff wiki page from the buildbot
* Make that wiki page exhaustive, and order it so that it's less a reference
for particular tasks and more an instruction list for everything you should
do as sheriff

PK

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

Re: [chromium-dev] Re: More sheriffs?

[Jeremy Orlow]

Maybe we should say at least one PST and at least one non-Americas?

Note that even if people outside of the Americas are getting
sheriff duty more often, the duty is lighter weight...so I think it balances
out fairly well.

As we get more non-Americas committers, we can think about adding
another...but I think things are fairly sane outside of normal PST business
hours for now.

On Fri, Nov 13, 2009 at 1:46 PM, Peter Kasting  wrote:

> It sounds like so far there is more support for the idea of three sheriffs
> than four.  What if I modify the proposal to be:
>
> * Change from two sheriffs to three
> * Try to ensure that one of those three is non-PST if this is possible
> without overloading teams outside MTV (this will probably get more and more
> feasible as we continue to build staff in Tokyo, London, etc.)
> * Try to ensure that at least one of those three has been a sheriff before
> * Link to the sheriff wiki page from the buildbot
> * Make that wiki page exhaustive, and order it so that it's less a
> reference for particular tasks and more an instruction list for everything
> you should do as sheriff
>
> PK
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-dev
>

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

[chromium-dev] Do people still use scons to build anymore?

[Chris Bentzel]

A number of pages on dev.chromium.org reference scons/hammer as the
default tools for Linux builds.

I've been using make just fine for the past week.

If make is the standard tool now, I'll volunteer to clean up the documentation.

Chris

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

[chromium-dev] building without svg

[Evan Martin]

I measured that SVG is nearly a sixth of the binary size of a Chrome
debug build.  That's not only more compile time, it's also more link
time for each incremental link and more time for the debugger to grind
it when starting gdb.  For my day-to-day debugging I would like to
build without SVG (and many other bits, but let's start with SVG).

I put on one obvious patch and one patch I'm not sure about at
  https://bugs.webkit.org/show_bug.cgi?id=31490

Does anyone have thoughts about the right way to disable SVG in the GYP files?
Here's the hacky second patch mentioned above:
  https://bug-31490-attachments.webkit.org/attachment.cgi?id=43196
In particular, I'm not sure of the right way to conditionally build
the SVGNames bits.

I've seen in some cases files are completely wrapped with "#if
ENABLE(FOO)"; do you know when that is appropriate?

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

Re: [chromium-dev] Do people still use scons to build anymore?

[王重傑]

We're still in the middle of switching.  I had made a pass over the docs a
few weeks ago, but I'm sure I missed some spots.  If you see any more spots,
or want to do another pass to make sure the docs push people towards the
make build by default, it'd be much appreciated!

Thanks,
Albert



On Fri, Nov 13, 2009 at 1:56 PM, Chris Bentzel  wrote:

> A number of pages on dev.chromium.org reference scons/hammer as the
> default tools for Linux builds.
>
> I've been using make just fine for the past week.
>
> If make is the standard tool now, I'll volunteer to clean up the
> documentation.
>
> Chris
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>

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

sheriff's keep the tree *open* WAS: [chromium-dev] More sheriffs?

[Ojan Vafai]

On Fri, Nov 13, 2009 at 1:25 PM, Peter Kasting  wrote:

> On Fri, Nov 13, 2009 at 1:15 PM, Finnur Thorarinsson wrote:
>
>> If the sheriff load is too much for two people to devote 100% of their
>> time to, then there is something wrong with the process.
>>
>
> It's clearly too much, given that I hardly see any other sheriffs even
> attempt to maintain the rule of "every bot green all the time", which is
> what you're supposed to do as sheriff.  And when I maintain it, I need to
> keep the tree closed for long periods while I deal with the myriad of issues
> that come up.
>

I don't think this is what sheriffs are supposed to do, although there is
clearly not consensus here. The goal of the sheriff is to keep the tree open
as long as possible without carpeting over regressions. The sheriff should
suffer through minor flakiness without closing the tree (e.g. a couple flaky
webkit tests should not close the tree).

I *do* think it is a team goal to have every bot green all the time, but
that goal is achieved by reducing flakiness, not by keeping the tree closed
until all the flakiness has been properly documented (e.g. listed in
test_expectations.txt). It's also a team goal to keep the tree open for >7
hours in every eight hour period. The latter is primarily the responsibility
of the sheriffs.


> Solving the problem by having the tree open if things "aren't too bad" is
> not good enough.  Right now I just checked and the purify and valgrind bots
> were red.  As usual.  No sign of anyone looking into them.
>

This is not a solution, but closing the tree doesn't really solve it either.
We need to put more burden on the sheriffs to watch and address these bots,
which, perhaps you're right that we should have more sheriffs.

Ojan

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

Re: [chromium-dev] building without svg

[Evan Martin]

We track total binary size here:
  http://build.chromium.org/buildbot/perf/dashboard/sizes.html

I don't know of any place we track per-module sizes.

On Fri, Nov 13, 2009 at 2:33 PM, Eric Seidel  wrote:
> Do we have any hard data about where our binary size goes?  It seems
> such data would be very useful.
>
> On Fri, Nov 13, 2009 at 2:14 PM, Evan Martin  wrote:
>> I measured that SVG is nearly a sixth of the binary size of a Chrome
>> debug build.  That's not only more compile time, it's also more link
>> time for each incremental link and more time for the debugger to grind
>> it when starting gdb.  For my day-to-day debugging I would like to
>> build without SVG (and many other bits, but let's start with SVG).
>>
>> I put on one obvious patch and one patch I'm not sure about at
>>  https://bugs.webkit.org/show_bug.cgi?id=31490
>>
>> Does anyone have thoughts about the right way to disable SVG in the GYP 
>> files?
>> Here's the hacky second patch mentioned above:
>>  https://bug-31490-attachments.webkit.org/attachment.cgi?id=43196
>> In particular, I'm not sure of the right way to conditionally build
>> the SVGNames bits.
>>
>> I've seen in some cases files are completely wrapped with "#if
>> ENABLE(FOO)"; do you know when that is appropriate?
>>
>> --
>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> View archives, change email options, or unsubscribe:
>>    http://groups.google.com/group/chromium-dev
>>
>

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

Re: [chromium-dev] building without svg

[Eric Seidel]

Do we have any hard data about where our binary size goes?  It seems
such data would be very useful.

On Fri, Nov 13, 2009 at 2:14 PM, Evan Martin  wrote:
> I measured that SVG is nearly a sixth of the binary size of a Chrome
> debug build.  That's not only more compile time, it's also more link
> time for each incremental link and more time for the debugger to grind
> it when starting gdb.  For my day-to-day debugging I would like to
> build without SVG (and many other bits, but let's start with SVG).
>
> I put on one obvious patch and one patch I'm not sure about at
>  https://bugs.webkit.org/show_bug.cgi?id=31490
>
> Does anyone have thoughts about the right way to disable SVG in the GYP files?
> Here's the hacky second patch mentioned above:
>  https://bug-31490-attachments.webkit.org/attachment.cgi?id=43196
> In particular, I'm not sure of the right way to conditionally build
> the SVGNames bits.
>
> I've seen in some cases files are completely wrapped with "#if
> ENABLE(FOO)"; do you know when that is appropriate?
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>    http://groups.google.com/group/chromium-dev
>

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

Re: sheriff's keep the tree *open* WAS: [chromium-dev] More sheriffs?

[Jeremy Orlow]

+1 (for what it's worth)

On Fri, Nov 13, 2009 at 2:28 PM, Ojan Vafai  wrote:

> On Fri, Nov 13, 2009 at 1:25 PM, Peter Kasting wrote:
>
>> On Fri, Nov 13, 2009 at 1:15 PM, Finnur Thorarinsson 
>> wrote:
>>
>>> If the sheriff load is too much for two people to devote 100% of their
>>> time to, then there is something wrong with the process.
>>>
>>
>> It's clearly too much, given that I hardly see any other sheriffs even
>> attempt to maintain the rule of "every bot green all the time", which is
>> what you're supposed to do as sheriff.  And when I maintain it, I need to
>> keep the tree closed for long periods while I deal with the myriad of issues
>> that come up.
>>
>
> I don't think this is what sheriffs are supposed to do, although there is
> clearly not consensus here. The goal of the sheriff is to keep the tree open
> as long as possible without carpeting over regressions. The sheriff should
> suffer through minor flakiness without closing the tree (e.g. a couple flaky
> webkit tests should not close the tree).
>
> I *do* think it is a team goal to have every bot green all the time, but
> that goal is achieved by reducing flakiness, not by keeping the tree closed
> until all the flakiness has been properly documented (e.g. listed in
> test_expectations.txt). It's also a team goal to keep the tree open for >7
> hours in every eight hour period. The latter is primarily the responsibility
> of the sheriffs.
>
>
>> Solving the problem by having the tree open if things "aren't too bad" is
>> not good enough.  Right now I just checked and the purify and valgrind bots
>> were red.  As usual.  No sign of anyone looking into them.
>>
>
> This is not a solution, but closing the tree doesn't really solve it
> either. We need to put more burden on the sheriffs to watch and address
> these bots, which, perhaps you're right that we should have more sheriffs.
>
> Ojan
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-dev

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

Re: [chromium-dev] Re: [chromium-extensions] openDatabase() maximum size

[Marcos Aruj]

It would be nice also for the user to know how much space an extension is
using. Like it is for memory usage right now.

On Fri, Nov 13, 2009 at 3:28 PM, Jeremy Orlow  wrote:

> On Fri, Nov 13, 2009 at 1:21 PM, Aaron Boodman  wrote:
>
>> On Fri, Nov 13, 2009 at 1:07 PM, Jeremy Orlow 
>> wrote:
>> > Just for the record, you're also the one who originally said it was fine
>> to
>> > limit them to 5mb (for LocalStorage anyhow).  :-)
>>
>> It is a consistent position to say "it is fine to limit it to 5mb for
>> now" and also say "it would be nice to allow additional space
>> someday". :)
>>
>> > What kind of extra space did you have in mind?  Unlimited?
>> > It's pretty late in the game to be making a decision like this for
>> mstone-4,
>> > but it might be possible if this was considered a major issue.
>>
>> Sorry, I didn't mean it for mstone 4, that is impossible. I'm just
>> saying in general, that I think it would be cool for extensions to be
>> able to request additional space. I await seeing what you guys come up
>> with for quota management for the web platform.
>>
>
> I think the plan for the web platform (for now anyhow) is that if you want
> more quota you need to install an extension.
>
> Are we OK with giving extensions unlimited storage space?  It seems like
> doing so would be reasonable as long as we gave the user the option to clean
> up the disk space when the extension is uninstalled.
>
> Either way, let's target something better (at least for extensions) for
> mstone 5.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Chromium-extensions" group.
> To post to this group, send email to chromium-extensi...@googlegroups.com.
> To unsubscribe from this group, send email to
> chromium-extensions+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/chromium-extensions?hl=.
>



-- 
Marcos Aruj Alvarez
Ingeniero de Software
---
marcos.a...@gmail.com
-

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

Re: [chromium-dev] More sheriffs?

[Dirk Pranke]

Having just come off sheriffing four days in the past two weeks ...

On Fri, Nov 13, 2009 at 12:31 PM, Peter Kasting  wrote:
> At lunch today, a few of us discussed the idea of moving from two sheriffs
> to four.
> There are several reasons we contemplated such a change:
> * The team is large enough that on the current schedule, you go months
> between sheriffing, which is so long that you forget things like what tools
> help you do what.

This is perhaps true, but I think it's more an issue that people don't
run more of the tests on their own machines (or, alternatively, are
asked to sheriff for areas of the system they never touch).

> * Sheriffing is a heavy burden, and getting moreso with more team members.
> * Either the two sheriffs are in different time zones, in which case you
> have effectively one sheriff on duty who has to do everything (bad due to
> point above), or they're not, in which case a chunk of the day is not
> covered at all.

I think two sheriffs in US/Pacific during US/Pacific work hours is
plenty. I can't speak to how much an issue the lack of sheriffs are to
people outside that window.

> * New sheriffs could really use a "mentor sheriff" with them, which is
> pretty difficult to schedule.

Last week was actually my first time, and I didn't think it was a big
deal, although I did ask a few people a few questions.

I was pretty much full time on keeping the tree green and cleaning up
flaky tests. Given that I'm otherwise full time on LTTF, this wasn't
much of a change. I think it's unrealistic to expect to do anything
real on a project while sheriffing, because you can't context-switch
that fast to do a good job on either (at least, I can't).

I also think the bots would've been green most of the time except that
someone has clearly been ignoring the memory tests for a long time. If
bots fails for a couple days straight, it's beyond a sheriff to try
and fix it - I think someone needs to get assigned that problem
specifically.

So, I'd probably leave things mostly the way they are unless there's a
desire to have better sheriffing outside of the MTV hours. I fully
support always having two sheriffs during MTV hours.

-- Dirk

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

Re: [chromium-dev] More sheriffs?

[Peter Kasting]

On Fri, Nov 13, 2009 at 2:56 PM, Dirk Pranke  wrote:

> I think two sheriffs in US/Pacific during US/Pacific work hours is
> plenty.
>

I was told at lunch that we already try to some degree to schedule PST with
non-PST people (although obvioulsy there are far more of the former), which
gives me the impression that there is a large percentage of time where we
have one, rather than two, sheriffs.  That is perhaps the most important
thing I'm trying to rectify in this proposal.

On Fri, Nov 13, 2009 at 2:58 PM, Nicolas Sylvain 
 wrote:

> As for http://dev.chromium.org/developers/tree-sheriffs, every sheriff
> receives it in the reminder email the day before they start their sheriff
> duty.
>

I see calendar reminder mails and think of them as conveying a reminder of
an event, so I'd never noticed that these mails also mention a web page I'm
supposed to be reading.  I know that is my own fault, but maybe there are
others in the same boat.  In any case, I still think Ben's suggestions would
be useful.

Overall I am surprised at how many people are skeptical of this proposal
given how unilaterally positive the smaller lunchtime discussion was.  I
guess I perceive us as not having a very effective sheriff system right
now--it's certainly been difficult for me--and am looking for ways to remedy
that.  It seems like those who aren't in favor of this generally wouldn't
agree with that assessment, and thus perceive this as adding overhead and
reducing effectiveness rather than combating a notable lack.  If that is
accurate, I'm not sure how to square the two worldviews.  I guess I will
leave this idea in the hands of the green tree task force to decide whether
it would be helpful.

PK

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

Re: [chromium-dev] More sheriffs?

[Jeremy Orlow]

On Fri, Nov 13, 2009 at 3:38 PM, Peter Kasting  wrote:

> On Fri, Nov 13, 2009 at 2:56 PM, Dirk Pranke  wrote:
>
>> I think two sheriffs in US/Pacific during US/Pacific work hours is
>> plenty.
>>
>
> I was told at lunch that we already try to some degree to schedule PST with
> non-PST people (although obvioulsy there are far more of the former), which
> gives me the impression that there is a large percentage of time where we
> have one, rather than two, sheriffs.  That is perhaps the most important
> thing I'm trying to rectify in this proposal.
>
> On Fri, Nov 13, 2009 at 2:58 PM, Nicolas Sylvain 
>  wrote:
>
>> As for http://dev.chromium.org/developers/tree-sheriffs, every sheriff
>> receives it in the reminder email the day before they start their sheriff
>> duty.
>>
>
> I see calendar reminder mails and think of them as conveying a reminder of
> an event, so I'd never noticed that these mails also mention a web page I'm
> supposed to be reading.  I know that is my own fault, but maybe there are
> others in the same boat.  In any case, I still think Ben's suggestions would
> be useful.
>
> Overall I am surprised at how many people are skeptical of this proposal
> given how unilaterally positive the smaller lunchtime discussion was.  I
> guess I perceive us as not having a very effective sheriff system right
> now--it's certainly been difficult for me--and am looking for ways to remedy
> that.  It seems like those who aren't in favor of this generally wouldn't
> agree with that assessment, and thus perceive this as adding overhead and
> reducing effectiveness rather than combating a notable lack.  If that is
> accurate, I'm not sure how to square the two worldviews.  I guess I will
> leave this idea in the hands of the green tree task force to decide whether
> it would be helpful.
>

It'd be interesting if others from lunch chimed in with why they think it's
a good idea.

Also, I think there was clear consensus in adding another sheriff so we
always have 2 in the Americas (or maybe even PST).  Do we know what the next
steps are to implement this?

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

Re: sheriff's keep the tree *open* WAS: [chromium-dev] More sheriffs?

[Peter Kasting]

On Fri, Nov 13, 2009 at 2:28 PM, Ojan Vafai  wrote:

> The goal of the sheriff is to keep the tree open as long as possible
> without carpeting over regressions. The sheriff should suffer through minor
> flakiness without closing the tree (e.g. a couple flaky webkit tests should
> not close the tree).
>

When I am sheriffing I keep the tree open until the point at which there is
redness that has no owner.  Normally, I take ownership of redness when I see
it, so this only occurs when multiple different things are red.  At that
point I close the tree until all redness has owners, at which point I
reopen.  I don't know how well that squares with your description.

that goal is achieved by reducing flakiness, not by keeping the tree closed
> until all the flakiness has been properly documented (e.g. listed in
> test_expectations.txt).
>

Are you suggesting not documenting the flakiness?  If not, then I suspect
that we are in fairly close agreement given my paragraph above.

It's also a team goal to keep the tree open for >7 hours in every eight hour
> period. The latter is primarily the responsibility of the sheriffs.
>

I see this as saying that the sheriff should prioritize tree openness over
tree greenness, which I disagree with.  Perhaps, though, you are not trying
to say that so strongly, and you're again saying something more akin to my
first paragraph above.

Solving the problem by having the tree open if things "aren't too bad" is
>> not good enough.  Right now I just checked and the purify and valgrind bots
>> were red.  As usual.  No sign of anyone looking into them.
>>
>
> This is not a solution, but closing the tree doesn't really solve it
> either.
>

I wasn't saying that closing the tree solved this problem.  I was saying
that the sheriff was not looking into these things, and that it was an
example of a general pattern where many sheriffs seem not to look into them,
and that not being busy dealing with these is one reason why other people
might perceive the current sheriff system as sufficient and effective more
than I do.

The entire reason I want more sheriffs is _precisely_ to hold the tree open
longer, because it means that when purify, valgrind, and layout tests all
fail, they can all get owners immediately and the tree can stay open.  Right
now it seems to me that either the tree is not open enough, or we sheriffs
are letting things slide.

PK

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

Re: [chromium-dev] Re: [chromium-extensions] openDatabase() maximum size

[Jeremy Orlow]

Bugged: http://code.google.com/p/chromium/issues/detail?id=27688

On Fri, Nov 13, 2009 at 2:30 PM, Marcos Aruj  wrote:

> It would be nice also for the user to know how much space an extension is
> using. Like it is for memory usage right now.
>
> On Fri, Nov 13, 2009 at 3:28 PM, Jeremy Orlow  wrote:
>
>> On Fri, Nov 13, 2009 at 1:21 PM, Aaron Boodman  wrote:
>>
>>> On Fri, Nov 13, 2009 at 1:07 PM, Jeremy Orlow 
>>> wrote:
>>> > Just for the record, you're also the one who originally said it was
>>> fine to
>>> > limit them to 5mb (for LocalStorage anyhow).  :-)
>>>
>>> It is a consistent position to say "it is fine to limit it to 5mb for
>>> now" and also say "it would be nice to allow additional space
>>> someday". :)
>>>
>>> > What kind of extra space did you have in mind?  Unlimited?
>>> > It's pretty late in the game to be making a decision like this for
>>> mstone-4,
>>> > but it might be possible if this was considered a major issue.
>>>
>>> Sorry, I didn't mean it for mstone 4, that is impossible. I'm just
>>> saying in general, that I think it would be cool for extensions to be
>>> able to request additional space. I await seeing what you guys come up
>>> with for quota management for the web platform.
>>>
>>
>> I think the plan for the web platform (for now anyhow) is that if you want
>> more quota you need to install an extension.
>>
>> Are we OK with giving extensions unlimited storage space?  It seems like
>> doing so would be reasonable as long as we gave the user the option to clean
>> up the disk space when the extension is uninstalled.
>>
>> Either way, let's target something better (at least for extensions) for
>> mstone 5.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Chromium-extensions" group.
>> To post to this group, send email to chromium-extensi...@googlegroups.com
>> .
>> To unsubscribe from this group, send email to
>> chromium-extensions+unsubscr...@googlegroups.com
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/chromium-extensions?hl=.
>>
>
>
>
> --
> Marcos Aruj Alvarez
> Ingeniero de Software
> ---
> marcos.a...@gmail.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: OWP feature owners: Please update the OWP roadmap.

[Jeremy Orlow]

Thanks Fumitoshi!

To _everyone_ else, please do this.  (ccing a bunch of people that might
have updates)

Also, I'm wondering if we shouldn't put our names on the list to make it
easier to know who to contact for information about a feature.  I personally
find it hard to keep up (one of the reasons this list is so incomplete).

On Thu, Nov 12, 2009 at 12:56 PM, Jeremy Orlow  wrote:

> Things here have gotten a little stale:
> http://dev.chromium.org/developers/web-platform-status  Can everyone
> working on OWP features please take a look and make sure what's written
> there syncs up with reality?
>
> To edit: Scroll to the bottom, click sign in, sign in, then click "edit
> page" at the top.
>
> Thanks!
> J
>

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

Re: [chromium-dev] building without svg

[Marc-Antoine Ruel]

Dean had done one, at least on Windows, I don't recall offhand since
it's been a while.

On Fri, Nov 13, 2009 at 5:39 PM, Evan Martin  wrote:
> We track total binary size here:
>  http://build.chromium.org/buildbot/perf/dashboard/sizes.html
>
> I don't know of any place we track per-module sizes.
>
> On Fri, Nov 13, 2009 at 2:33 PM, Eric Seidel  wrote:
>> Do we have any hard data about where our binary size goes?  It seems
>> such data would be very useful.
>>
>> On Fri, Nov 13, 2009 at 2:14 PM, Evan Martin  wrote:
>>> I measured that SVG is nearly a sixth of the binary size of a Chrome
>>> debug build.  That's not only more compile time, it's also more link
>>> time for each incremental link and more time for the debugger to grind
>>> it when starting gdb.  For my day-to-day debugging I would like to
>>> build without SVG (and many other bits, but let's start with SVG).
>>>
>>> I put on one obvious patch and one patch I'm not sure about at
>>>  https://bugs.webkit.org/show_bug.cgi?id=31490
>>>
>>> Does anyone have thoughts about the right way to disable SVG in the GYP 
>>> files?
>>> Here's the hacky second patch mentioned above:
>>>  https://bug-31490-attachments.webkit.org/attachment.cgi?id=43196
>>> In particular, I'm not sure of the right way to conditionally build
>>> the SVGNames bits.
>>>
>>> I've seen in some cases files are completely wrapped with "#if
>>> ENABLE(FOO)"; do you know when that is appropriate?
>>>
>>> --
>>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>>> View archives, change email options, or unsubscribe:
>>>    http://groups.google.com/group/chromium-dev
>>>
>>
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>    http://groups.google.com/group/chromium-dev
>

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

Re: [chromium-dev] Any interest in command line tools for network stack?

[Wan-Teh Chang]

On Fri, Nov 13, 2009 at 11:58 AM, Chris Bentzel  wrote:
> I'm using them as a learning exercise for the network stack - and I'm
> guessing that they will help debug behavior in the future as well.
>
> I don't intend to add additional functionality over the standard tools
> - in fact, I promise you they'll be less functional than the standard
> tools. For example, my hresolv executable just takes a hostname and a
> port as options for now.
>
> I'll spend a bit more time getting them to a reasonable point and send
> a patch out for review - figure decision will be easier then over a
> vague description.

I also like the idea.  These tools can serve as sample code
for other projects that are considering taking our network
stack.  It can also be easier to debug a simple command
line tool than a full-blown browser if a network stack bug
can be reproduced using a command line tool.

Wan-Teh

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

[chromium-dev] Need help from IME experts

[Nico Weber]

Hi,

I would appreciate if folks with IME experience could comment on
https://bugs.webkit.org/show_bug.cgi?id=31502 .

Thanks,
Nico

ps: If similar mails like this one are sent to, please ignore them.
Gmail or groups is acting up.

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

Re: [chromium-dev] Need help from IME experts

[Peter Kasting]

On Fri, Nov 13, 2009 at 6:01 PM, Nico Weber  wrote:

> I would appreciate if folks with IME experience could comment on
> https://bugs.webkit.org/show_bug.cgi?id=31502 .


+CC jshin

PK

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

Re: sheriff's keep the tree *open* WAS: [chromium-dev] More sheriffs?

[Mark Mentovai]

Ojan Vafai  wrote:
> I don't think this is what sheriffs are supposed to do, although there is
> clearly not consensus here. The goal of the sheriff is to keep the tree open
> as long as possible without carpeting over regressions. The sheriff should
> suffer through minor flakiness without closing the tree (e.g. a couple flaky
> webkit tests should not close the tree).

YES.  This is important, and I want to expand on it.

A good sheriff doesn’t just open and close the tree.  A good sheriff
actively monitors and manages the tree.

As much as we might want to codify how to respond to certain
situations, I think that the best sheriffs rely on experience and good
judgment more than anything else.  Don’t read that to mean that we
shouldn’t document sheriffing duties and tools, I think that’s
important too.  What might be even more helpful to a rookie (or a bad
sheriff) would be to watch a good sheriff work through a troublesome
tree before the rookie’s own number is up.

If our tree were completely flake-free, we could rely on tools to keep
things green, and we wouldn’t need sheriffs at all, or at least not in
the same capacity that we need them today.  Unfortunately, we’re not
there yet.  Until that problem is solved, we need the shades of gray
between “the tree should be open” and “the tree should be closed” that
a good sheriff’s human judgment provides.

Mark

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

Re: [chromium-dev] More sheriffs?

[Mark Mentovai]

Peter Kasting wrote:
> On Fri, Nov 13, 2009 at 12:44 PM, Stuart Morgan 
> wrote:
>>
>> If we end up actually having four at a time that seems likely to be
>> worse than two: either four people are doing nothing but sheriffing,
>> which there is probably not enough work for, or all four people are
>> more likely to think that someone else is probably watching and they
>> can do something else.

I didn’t see Stuart’s original message, so I don’t know if there was
more context, but I agree with what he’s saying here.  In my
experience, sheriffing is a one-person job, except we want that one
person to be able to take a break or have lunch or have someone to
fall back on when there are compound problems.  I think it’s actually
pretty rare for there to be more than three things wrong at a time,
and usually when there are that many wrong, they didn’t all go bad
simultaneously.  It’s a one-person job, but it’s more than a full-time
job, so we schedule two.

Recently, there have been a few cases where people on the schedule
couldn’t sheriff and didn’t arrange for a replacement.  Things have
gotten really bad when this happened, and for that reason alone, I’d
support going to three.

I also agree that going three months between shifts means that you
might lose touch with how to do it effectively.  Maybe we’ve got
enough people now that we don’t need to sheriff for two days at a
time.  Maybe we can move from two sheriffs for two days to three for
one.

I’m not terribly motivated by any of the time zone policies, because I
haven't seen this as a significant source of problems.

Mark

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