Change builder names

Change Builder Names, MkIII

Inspired by Ravi's comments on https://codereview.chromium.org/14475006/

- Use a dictionary of tuples to specify the builders in master_builders_cfg.
  This is much more readable and allows at-a-glance comparison.  The downside
  is that the line width is insanely long.
- Slightly restructure the builder names to use a full architecture spec rather
  than an arch width.  This allows us, for example, to differentiate between a
  32-bit ChromeOS compile bot targeting x86 and one targeting arm.

[borenet, 2013-04-09 16:31:46]

Patch set 1 is just testing the waters.

Overall, I'd like the names to be even shorter.  There are certainly places
where we have unnecessary or duplicated information, but for this patch set I
focused on standardizing everything.  A totally different direction to take this
would be to make these names ridiculously short but machine-parseable and then
do a lookup somewhere for more information when we want to present it to a
human.  For example, "Linux-Ubuntu12-32-ATI5770-Debug" could shorten to
"U12-32-ATI5770-D" or something even more compressed ("L1234"?) and could be
expanded to a nice, human-readable form when we request it: "Linux Ubuntu12
32-bit ATI5770 Debug".

Thoughts?

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py
File master/master_builders_cfg.py (right):

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py...
master/master_builders_cfg.py:59: version='Ubuntu12',
Do we need "Linux" here?  Or could we just say os='Ubuntu' and version='12'?

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py...
master/master_builders_cfg.py:85: os='Android',
We can probably infer from the device name that the OS is Android, but I think
it's simpler to include it here.

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py...
master/master_builders_cfg.py:86: version='4.1',
Does the '.' break the "no funny characters" rule?  We can use an underscore
instead if necessary.

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py...
master/master_builders_cfg.py:98: version='4.1',
We keep our Android devices pretty up-to-date.  Only a couple of them are still
running 4.1.  I don't think we want to keep updating this number when we flash
new builds to devices.

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py...
master/master_builders_cfg.py:175: hardware='MacMini',
We can probably be more specific than MacMini, right?  Like GPU vendor, etc?  Do
all MacMinis have the same GPU?

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py...
master/master_builders_cfg.py:261: hardware='Intel',
This refers to the Intel integrated graphics.  The meaning of "hardware" is a
little ambiguous to me; it could mean the form factor or computer type (MacMini)
OR it could be the type of GPU.  I hesitate to include both types of
information, since our machines are all either MacMini or Shuttle.  Maybe
"hardware" should just become "gpu".

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py...
master/master_builders_cfg.py:292: extra_config='ANGLE',
"extra_config" seemed like the best way to describe things like "ANGLE" and
"DirectWrite".  Thoughts?

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py...
master/master_builders_cfg.py:349: hardware='NoGPU',
NoGPU is more of an extra_config than a hardware type, but it doesn't make much
sense to say "Intel" or "ATI5770" and then "NoGPU".

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py...
master/master_builders_cfg.py:365: hardware='NaCl',
NaCl isn't hardware at all.  Maybe this is an extra_config too?

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py...
master/master_builders_cfg.py:379: version='V',
AFAIK the ChromeOS version gets updated automatically.  I don't think we want to
have to change this number with each update.

https://codereview.chromium.org/13861012/diff/1/master/skia_master_scripts/ut...
File master/skia_master_scripts/utils.py (right):

https://codereview.chromium.org/13861012/diff/1/master/skia_master_scripts/ut...
master/skia_master_scripts/utils.py:37: BUILDER_NAME_SEP = '-'
Changed from the '_' which we used before to separate parts of builder names. 
IMO things joined with underscores group before things joined with dashes, for
example:
a_b-c_d-e

Groups to:
(a_b), (c_d), (e)

https://codereview.chromium.org/13861012/diff/1/master/skia_master_scripts/ut...
master/skia_master_scripts/utils.py:379: extra_config))
I already removed this duplicate check.

https://codereview.chromium.org/13861012/diff/1/master/skia_master_scripts/ut...
master/skia_master_scripts/utils.py:415: gm_image_subdir, extra_config=None,
Passing these extra parameters is annoying, particularly since they only
contribute to the builder name.  Here are some alternatives I thought of:
- Call this function in master_builders_cfg and pass in the created name,
similar to how we did it before
- Collect these parameters into an object or dictionary

https://codereview.chromium.org/13861012/diff/1/master/skia_master_scripts/ut...
master/skia_master_scripts/utils.py:570: ('PerCommit-Housekeeping',
I'd really like to make the housekeepers conform to the same convention.  I
guess the name would be something like
Linux-Ubuntu12-VM-PerCommit_Housekeeping...

https://codereview.chromium.org/13861012/diff/1/master/slaves.cfg
File master/slaves.cfg (right):

https://codereview.chromium.org/13861012/diff/1/master/slaves.cfg#newcode1
master/slaves.cfg:1: # -*- python -*-
Check out the united diff to see how the name lengths changed.

[benchen, 2013-04-09 16:45:49]

I like heavy abbreviations, but we shuld come up with a system and ask the whole
team if they all agree on it.
first part: One letter for OS, followed by a number for version
second part: hardware specs
third part: one letter for purpose, D or B
other parts: ?
Reminds me of UPC barcodes, but need to be easily decodable.

[rmistry, 2013-04-09 16:48:10]

The abbreviations will show up on the buildbot pages and rietveld tryjobs popup?
If yes then I prefer the longer: Linux-Ubuntu12-32-ATI5770-Debug else it will be
too difficult to parse for most.

[epoger, 2013-04-09 17:38:36]

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py
File master/master_builders_cfg.py (right):

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py...
master/master_builders_cfg.py:1: # Copyright (c) 2012 The Chromium Authors. All
rights reserved.
regarding builder name length, whether to use abbreviations, etc.:

I think the thing we need to know first is: where do these builder names show
up?  And in those places, what are the nice-to-haves/need-to-haves about the
builder names?  (including length constraints)

I do not think it's a good idea to use nonobvious abbreviations in user-facing
places (e.g. buildbot pages and rietveld tryjobs popup).  In those places, I
think developers will be frustrated unless the names are self-contained (i.e.,
they can be mostly understood WITHOUT referencing a separate lookup table).  I
think we can have *some* stuff in a lookup table, like "MacMiniA" vs "MacMiniB"
to refer to different revisions of MacMini hardware.

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py...
master/master_builders_cfg.py:59: version='Ubuntu12',
On 2013/04/09 16:31:46, borenet wrote:
> Do we need "Linux" here?  Or could we just say os='Ubuntu' and version='12'?

I think either one is fine.  I would say that "Ubuntu" is a reasonable way of
abbreviating "Ubuntu Linux".

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py...
master/master_builders_cfg.py:85: os='Android',
On 2013/04/09 16:31:46, borenet wrote:
> We can probably infer from the device name that the OS is Android, but I think
> it's simpler to include it here.

Agreed.

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py...
master/master_builders_cfg.py:86: version='4.1',
On 2013/04/09 16:31:46, borenet wrote:
> Does the '.' break the "no funny characters" rule?  We can use an underscore
> instead if necessary.

It's often handy to use dots within version numbers, so I think underscore is
good as a field separator and then allow dots within any field.

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py...
master/master_builders_cfg.py:98: version='4.1',
On 2013/04/09 16:31:46, borenet wrote:
> We keep our Android devices pretty up-to-date.  Only a couple of them are
still
> running 4.1.  I don't think we want to keep updating this number when we flash
> new builds to devices.

If we don't intend to update this number, we should probably just leave the
field blank for these builders.  (Or use a "blank equivalent" value, like "x")

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py...
master/master_builders_cfg.py:175: hardware='MacMini',
On 2013/04/09 16:31:46, borenet wrote:
> We can probably be more specific than MacMini, right?  Like GPU vendor, etc? 
Do
> all MacMinis have the same GPU?

No, different revs of the MacMini will vary a bit.  I suggest "MacMiniA",
"MacMiniB", or some similar variations.

One idea could be to use the Machine Model IDs as listed in
http://en.wikipedia.org/wiki/Mac_Mini#Specifications_3 : "Macmini4,1", etc. 
Although there are even sometimes variations within a model ID...

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py...
master/master_builders_cfg.py:261: hardware='Intel',
On 2013/04/09 16:31:46, borenet wrote:
> This refers to the Intel integrated graphics.  The meaning of "hardware" is a
> little ambiguous to me; it could mean the form factor or computer type
(MacMini)
> OR it could be the type of GPU.  I hesitate to include both types of
> information, since our machines are all either MacMini or Shuttle.  Maybe
> "hardware" should just become "gpu".

I think it would be a good idea to split this into two fields: 1.GPU and
2.computer type (this would imply CPU, memory, and other chipset parts).

I think we *could* leave the "computer type" field blank for now, if you like
(because it's either MacMini or Shuttle in most cases).  Or, to avoid schema
changes in the future, we could use IDs like these: Macmini4,1 Macmini5,1 
MacPro3,1  ShuttleA  GCE  etc.

For our current Shuttle build ("ShuttleA" -> Intel core i7-2600, etc.), the GPU
field could read "integrated", or maybe "HD4000"...

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py...
master/master_builders_cfg.py:292: extra_config='ANGLE',
On 2013/04/09 16:31:46, borenet wrote:
> "extra_config" seemed like the best way to describe things like "ANGLE" and
> "DirectWrite".  Thoughts?

Sure.

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py...
master/master_builders_cfg.py:349: hardware='NoGPU',
On 2013/04/09 16:31:46, borenet wrote:
> NoGPU is more of an extra_config than a hardware type, but it doesn't make
much
> sense to say "Intel" or "ATI5770" and then "NoGPU".

I think NoGPU should be listed as extra_config, because it describes some extra
configs that were passed to the build, NOT characteristics of the machine on
which the tests were run.

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py...
master/master_builders_cfg.py:365: hardware='NaCl',
On 2013/04/09 16:31:46, borenet wrote:
> NaCl isn't hardware at all.  Maybe this is an extra_config too?

Yes, seems more like extra_config

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py...
master/master_builders_cfg.py:379: version='V',
On 2013/04/09 16:31:46, borenet wrote:
> AFAIK the ChromeOS version gets updated automatically.  I don't think we want
to
> have to change this number with each update.

Agreed.  Blank, or 'x', something like that.

https://codereview.chromium.org/13861012/diff/1/master/skia_master_scripts/ut...
File master/skia_master_scripts/utils.py (right):

https://codereview.chromium.org/13861012/diff/1/master/skia_master_scripts/ut...
master/skia_master_scripts/utils.py:37: BUILDER_NAME_SEP = '-'
On 2013/04/09 16:31:46, borenet wrote:
> Changed from the '_' which we used before to separate parts of builder names. 
> IMO things joined with underscores group before things joined with dashes, for
> example:
> a_b-c_d-e
> 
> Groups to:
> (a_b), (c_d), (e)

Agreed.

https://codereview.chromium.org/13861012/diff/1/master/slaves.cfg
File master/slaves.cfg (right):

https://codereview.chromium.org/13861012/diff/1/master/slaves.cfg#newcode310
master/slaves.cfg:310: 'Linux-Ubuntu12-32-ATI5770-Debug',
With the changes discussed above, I think this will end up more like:

Ubuntu-12-32-ShuttleA-ATI5770-Release

Actually, I would advocate moving 32/64 to the end, to separate it from the
other numeric field (OS version):

Ubuntu-12-ShuttleA-ATI5770-Release-32

https://codereview.chromium.org/13861012/diff/1/master/slaves.cfg#newcode362
master/slaves.cfg:362: 'OSX-10.8-32-MacMini-Debug',
Or maybe...

Mac-10.8-Macmini4,1-integrated-Debug-32

(or whatever the Macmini version is, I just made this one up)

https://codereview.chromium.org/13861012/diff/1/master/slaves.cfg#newcode394
master/slaves.cfg:394: 'Win-7-32-Intel-ANGLE-Debug',
I would think extra_config would go at the END, and this would instead read:

Win-7.0-ShuttleA-integrated-Debug-32-ANGLE

(Windows version "7.0" gives us room to distinguish between OS update versions)

[borenet, 2013-04-09 19:11:45]

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py
File master/master_builders_cfg.py (right):

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py...
master/master_builders_cfg.py:1: # Copyright (c) 2012 The Chromium Authors. All
rights reserved.
On 2013/04/09 17:38:36, epoger wrote:
> regarding builder name length, whether to use abbreviations, etc.:
> 
> I think the thing we need to know first is: where do these builder names show
> up?  And in those places, what are the nice-to-haves/need-to-haves about the
> builder names?  (including length constraints)
> 

1. Trybots on Rietveld - we want to see the minimal amount of information to
identify the platforms we want while reducing the giant size of the list. 
Unfortunately, we can't insert information from a lookup table here.
2. Trybots from submit_try - same as #1 except that we can get around too-long
or short and uninformative builder names through the use of filters and lists.
3. Bench dashboard - Related to #1 and #2 - Really, it's better to obtain and
use the relevant information, either from the builder name or using a lookup,
than to display the builder name itself.  For example, choose data by OS and
hardware rather than picking from a list of builder names.
4. Buildbot pages - I don't think it's as bad to have very short names here,
since the webpages themselves contain more information (OS, hardware, etc)

> I do not think it's a good idea to use nonobvious abbreviations in user-facing
> places (e.g. buildbot pages and rietveld tryjobs popup).  In those places, I
> think developers will be frustrated unless the names are self-contained (i.e.,
> they can be mostly understood WITHOUT referencing a separate lookup table).  I
> think we can have *some* stuff in a lookup table, like "MacMiniA" vs
"MacMiniB"
> to refer to different revisions of MacMini hardware.
>

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py...
master/master_builders_cfg.py:59: version='Ubuntu12',
On 2013/04/09 17:38:36, epoger wrote:
> On 2013/04/09 16:31:46, borenet wrote:
> > Do we need "Linux" here?  Or could we just say os='Ubuntu' and version='12'?
> 
> I think either one is fine.  I would say that "Ubuntu" is a reasonable way of
> abbreviating "Ubuntu Linux".

Agreed.  I just want to be consistent - if we use Ubuntu here, we shouldn't use
Linux anywhere else.

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py...
master/master_builders_cfg.py:98: version='4.1',
On 2013/04/09 17:38:36, epoger wrote:
> On 2013/04/09 16:31:46, borenet wrote:
> > We keep our Android devices pretty up-to-date.  Only a couple of them are
> still
> > running 4.1.  I don't think we want to keep updating this number when we
flash
> > new builds to devices.
> 
> If we don't intend to update this number, we should probably just leave the
> field blank for these builders.  (Or use a "blank equivalent" value, like "x")

My only problem with this is that it wastes characters.  However, leaving the
field out will make parsing harder, since we'll have to guess which fields are
filled in.

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py...
master/master_builders_cfg.py:349: hardware='NoGPU',
On 2013/04/09 17:38:36, epoger wrote:
> On 2013/04/09 16:31:46, borenet wrote:
> > NoGPU is more of an extra_config than a hardware type, but it doesn't make
> much
> > sense to say "Intel" or "ATI5770" and then "NoGPU".
> 
> I think NoGPU should be listed as extra_config, because it describes some
extra
> configs that were passed to the build, NOT characteristics of the machine on
> which the tests were run.

If a gpu field is added, that's where NoGPU should go.

[epoger, 2013-04-09 19:16:12]

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py
File master/master_builders_cfg.py (right):

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py...
master/master_builders_cfg.py:98: version='4.1',
On 2013/04/09 19:11:45, borenet wrote:
> On 2013/04/09 17:38:36, epoger wrote:
> > On 2013/04/09 16:31:46, borenet wrote:
> > > We keep our Android devices pretty up-to-date.  Only a couple of them are
> > still
> > > running 4.1.  I don't think we want to keep updating this number when we
> flash
> > > new builds to devices.
> > 
> > If we don't intend to update this number, we should probably just leave the
> > field blank for these builders.  (Or use a "blank equivalent" value, like
"x")
> 
> My only problem with this is that it wastes characters.  However, leaving the
> field out will make parsing harder, since we'll have to guess which fields are
> filled in.

Yeah, the extra 2 characters ("-x-" instead of "-") seems like a small price to
pay.

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py...
master/master_builders_cfg.py:349: hardware='NoGPU',
On 2013/04/09 19:11:45, borenet wrote:
> On 2013/04/09 17:38:36, epoger wrote:
> > On 2013/04/09 16:31:46, borenet wrote:
> > > NoGPU is more of an extra_config than a hardware type, but it doesn't make
> > much
> > > sense to say "Intel" or "ATI5770" and then "NoGPU".
> > 
> > I think NoGPU should be listed as extra_config, because it describes some
> extra
> > configs that were passed to the build, NOT characteristics of the machine on
> > which the tests were run.
> 
> If a gpu field is added, that's where NoGPU should go.

I can see arguments either way (either gpu field or extra_config field).  Either
way should be fine.

[borenet, 2013-04-09 19:30:09]

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py
File master/master_builders_cfg.py (right):

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py...
master/master_builders_cfg.py:98: version='4.1',
On 2013/04/09 19:16:12, epoger wrote:
> On 2013/04/09 19:11:45, borenet wrote:
> > On 2013/04/09 17:38:36, epoger wrote:
> > > On 2013/04/09 16:31:46, borenet wrote:
> > > > We keep our Android devices pretty up-to-date.  Only a couple of them
are
> > > still
> > > > running 4.1.  I don't think we want to keep updating this number when we
> > flash
> > > > new builds to devices.
> > > 
> > > If we don't intend to update this number, we should probably just leave
the
> > > field blank for these builders.  (Or use a "blank equivalent" value, like
> "x")
> > 
> > My only problem with this is that it wastes characters.  However, leaving
the
> > field out will make parsing harder, since we'll have to guess which fields
are
> > filled in.
> 
> Yeah, the extra 2 characters ("-x-" instead of "-") seems like a small price
to
> pay.

My ideal is to take a dictionary or object like this:

{ 'os': 'Ubuntu',
  'version': '12',
  'arch_width': '32',
  'gpu': 'ATI5770' }

And convert that into a builder name which contains all of that information in a
human-readable but concise form.  However, the question of what to do with blank
fields remains.  Here are a couple of options I can think of:
1. Use a single-character placeholder "x"
2. Use an empty string, eg. "Android--32-Xoom"
3. Include the keys of the dictionary somehow, eg
"os_Ubuntu-v_12-arch_64-gpu_ATI5770-role_Debug".  This adds more characters than
I'd like, but it would guarantee that we could parse back into dictionary form
even if we left out or re-ordered fields.

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py...
master/master_builders_cfg.py:349: hardware='NoGPU',
On 2013/04/09 19:16:12, epoger wrote:
> On 2013/04/09 19:11:45, borenet wrote:
> > On 2013/04/09 17:38:36, epoger wrote:
> > > On 2013/04/09 16:31:46, borenet wrote:
> > > > NoGPU is more of an extra_config than a hardware type, but it doesn't
make
> > > much
> > > > sense to say "Intel" or "ATI5770" and then "NoGPU".
> > > 
> > > I think NoGPU should be listed as extra_config, because it describes some
> > extra
> > > configs that were passed to the build, NOT characteristics of the machine
on
> > > which the tests were run.
> > 
> > If a gpu field is added, that's where NoGPU should go.
> 
> I can see arguments either way (either gpu field or extra_config field). 
Either
> way should be fine.

I think this is an interesting distinction.  For the NoGPU bot, we *don't care*
what GPU the machine itself has.  For most bots, the builder corresponds pretty
directly to a specific machine setup, but for NoGPU and the Compile bots, it
doesn't matter.

[epoger, 2013-04-09 19:40:13]

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py
File master/master_builders_cfg.py (right):

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py...
master/master_builders_cfg.py:98: version='4.1',
On 2013/04/09 19:30:09, borenet wrote:
> On 2013/04/09 19:16:12, epoger wrote:
> > On 2013/04/09 19:11:45, borenet wrote:
> > > On 2013/04/09 17:38:36, epoger wrote:
> > > > On 2013/04/09 16:31:46, borenet wrote:
> > > > > We keep our Android devices pretty up-to-date.  Only a couple of them
> are
> > > > still
> > > > > running 4.1.  I don't think we want to keep updating this number when
we
> > > flash
> > > > > new builds to devices.
> > > > 
> > > > If we don't intend to update this number, we should probably just leave
> the
> > > > field blank for these builders.  (Or use a "blank equivalent" value,
like
> > "x")
> > > 
> > > My only problem with this is that it wastes characters.  However, leaving
> the
> > > field out will make parsing harder, since we'll have to guess which fields
> are
> > > filled in.
> > 
> > Yeah, the extra 2 characters ("-x-" instead of "-") seems like a small price
> to
> > pay.
> 
> My ideal is to take a dictionary or object like this:
> 
> { 'os': 'Ubuntu',
>   'version': '12',
>   'arch_width': '32',
>   'gpu': 'ATI5770' }
> 
> And convert that into a builder name which contains all of that information in
a
> human-readable but concise form.  However, the question of what to do with
blank
> fields remains.  Here are a couple of options I can think of:
> 1. Use a single-character placeholder "x"
> 2. Use an empty string, eg. "Android--32-Xoom"
> 3. Include the keys of the dictionary somehow, eg
> "os_Ubuntu-v_12-arch_64-gpu_ATI5770-role_Debug".  This adds more characters
than
> I'd like, but it would guarantee that we could parse back into dictionary form
> even if we left out or re-ordered fields.

I like the idea of keeping the information as a directory, and then expressing
it as directly as possible in the builder name.

I think including the keys in the builder name will be really unwieldy for
humans.  I think option #1 is the best.

https://codereview.chromium.org/13861012/diff/1/master/master_builders_cfg.py...
master/master_builders_cfg.py:349: hardware='NoGPU',
On 2013/04/09 19:30:09, borenet wrote:
> On 2013/04/09 19:16:12, epoger wrote:
> > On 2013/04/09 19:11:45, borenet wrote:
> > > On 2013/04/09 17:38:36, epoger wrote:
> > > > On 2013/04/09 16:31:46, borenet wrote:
> > > > > NoGPU is more of an extra_config than a hardware type, but it doesn't
> make
> > > > much
> > > > > sense to say "Intel" or "ATI5770" and then "NoGPU".
> > > > 
> > > > I think NoGPU should be listed as extra_config, because it describes
some
> > > extra
> > > > configs that were passed to the build, NOT characteristics of the
machine
> on
> > > > which the tests were run.
> > > 
> > > If a gpu field is added, that's where NoGPU should go.
> > 
> > I can see arguments either way (either gpu field or extra_config field). 
> Either
> > way should be fine.
> 
> I think this is an interesting distinction.  For the NoGPU bot, we *don't
care*
> what GPU the machine itself has.  For most bots, the builder corresponds
pretty
> directly to a specific machine setup, but for NoGPU and the Compile bots, it
> doesn't matter.

Agreed on all points.

[borenet, 2013-04-11 20:11:20]

Based on feedback, I'm sensing that the general feeling is that, since the raw
builder names are displayed directly to the user in several places, it's not a
good idea to shorten the builder names to the point where they aren't
human-readable.  To me, this suggests that the right way to go is a system
similar what we're using now, in that the relevant information is included in
the builder name, but also removes any unnecessary information and is in a
standard form so that it's easily machine-parseable.  Maybe we should meet to
gather our thoughts  about this before I upload a "real" CL?

[rmistry, 2013-04-11 20:15:29]

On 2013/04/11 20:11:20, borenet wrote:
> Based on feedback, I'm sensing that the general feeling is that, since the raw
> builder names are displayed directly to the user in several places, it's not a
> good idea to shorten the builder names to the point where they aren't
> human-readable.  To me, this suggests that the right way to go is a system
> similar what we're using now, in that the relevant information is included in
> the builder name, but also removes any unnecessary information and is in a
> standard form so that it's easily machine-parseable.  Maybe we should meet to
> gather our thoughts  about this before I upload a "real" CL?

Agreed. My opinion is we do not need to maintain two different name sets (user
friendly and machine readable). They should be the same and they should be human
parsable.

[benchen, 2013-04-11 20:29:52]

I suggest a team-wide discussion, since what we like may not be what our users
(developers) do. How about writing a doc summarizing our thoughts, then get
their approvals/suggestions?

[rmistry, 2013-04-11 20:37:53]

On 2013/04/11 20:29:52, benchen wrote:
> I suggest a team-wide discussion, since what we like may not be what our users
> (developers) do. How about writing a doc summarizing our thoughts, then get
> their approvals/suggestions?

Alternatively (or maybe similarly), we could among the infrastructure team,
discuss and come up with a naming convention that we think would work, and then
send that out to the wider team to get feedback. I doubt that what we like will
not be what our users will like (since we are the ones who spend the most time
staring at these names).

[rmistry, 2013-04-11 20:46:38]

On 2013/04/11 20:37:53, rmistry wrote:
> On 2013/04/11 20:29:52, benchen wrote:
> > I suggest a team-wide discussion, since what we like may not be what our
users
> > (developers) do. How about writing a doc summarizing our thoughts, then get
> > their approvals/suggestions?
> 
> Alternatively (or maybe similarly), we could among the infrastructure team,
> discuss and come up with a naming convention that we think would work, and
then
> send that out to the wider team to get feedback. I doubt that what we like
will
> not be what our users will like (since we are the ones who spend the most time
> staring at these names).

Lets talk about this in the meeting on Tuesday, I was going to setup some time
earlier but Ben is OOO half day tomorrow and Elliot is OOO on Monday.

[benchen, 2013-04-11 20:58:40]

Sounds good. Sorry I omitted this step I meant to have - of course to come up
with our proposal we need to meet and get into agreement first :)

[borenet, 2013-04-17 17:50:15]

Uploaded patch set 2.  My primary concerns:

1. 'hardware' vs 'gpu'.  The current set of builders doesn't make a distinction.
 Is that wrong?  In most cases we won't need two fields, but as we've discussed,
"MacMini" isn't descriptive enough.  For compile-only bots, we probably don't
want EITHER of these fields, since they don't test a hardware configuration and
therefore simply don't matter.  Should I hard-code an exclusion of these fields
when creating the compile builder?

2. There are 40 instances of "-x-", or 80 if you include the trybots.  All of
them are OS versions for Android and ChromeOS.  I think that not including a
version for these bots is the right thing to do, but I don't like the way it
looks.

3. General question about the compile bots: I don't particularly like the
"CompileDebug" names, but I don't know of a better way.  Also of note is the
fact that, for the most part, these builder names consist of the TARGET for
which they build, rather than the platform on which they're building.  In some
cases, we care about testing builds in different IDE versions, etc, but to say
that our Mac compile bots, for example, are Mac Minis, is flat-out wrong in most
cases, even though from a practical standpoint it doesn't matter that they
really run on Mac Pros.  A possible solution (which would add a LOT of
complexity) is to split out the compile bots so that they can be named
differently based on the aspects we care about, eg.
"Win-7-Intel-32-DebugCompile" becomes "Win-7-VS2010-DebugCompile" to denote that
we're building on VS 2010, and we simply don't care whether it has Intel
integrated graphics or what.  Another example:
"OSX-10_8-MacMini-32-DebugCompile" --> "OSX-10_8-XCode4.6-32-DebugCompile". 
Thoughts?

https://codereview.chromium.org/13861012/diff/13001/master/master_builders_cf...
File master/master_builders_cfg.py (right):

https://codereview.chromium.org/13861012/diff/13001/master/master_builders_cf...
master/master_builders_cfg.py:86: version=None,
At Derek's suggestion, I excluded the Android version altogether.  The Android
bots will be kept up-to-date, and we don't want to have to rename the builders.

[borenet, 2013-04-17 18:11:29]

On 2013/04/17 17:50:15, borenet wrote:
> Uploaded patch set 2.  My primary concerns:
> 
> 1. 'hardware' vs 'gpu'.  The current set of builders doesn't make a
distinction.
>  Is that wrong?  In most cases we won't need two fields, but as we've
discussed,
> "MacMini" isn't descriptive enough.  For compile-only bots, we probably don't
> want EITHER of these fields, since they don't test a hardware configuration
and
> therefore simply don't matter.  Should I hard-code an exclusion of these
fields
> when creating the compile builder?
> 
> 2. There are 40 instances of "-x-", or 80 if you include the trybots.  All of
> them are OS versions for Android and ChromeOS.  I think that not including a
> version for these bots is the right thing to do, but I don't like the way it
> looks.
> 
> 3. General question about the compile bots: I don't particularly like the
> "CompileDebug" names, but I don't know of a better way.  Also of note is the
> fact that, for the most part, these builder names consist of the TARGET for
> which they build, rather than the platform on which they're building.  In some
> cases, we care about testing builds in different IDE versions, etc, but to say
> that our Mac compile bots, for example, are Mac Minis, is flat-out wrong in
most
> cases, even though from a practical standpoint it doesn't matter that they
> really run on Mac Pros.  A possible solution (which would add a LOT of
> complexity) is to split out the compile bots so that they can be named
> differently based on the aspects we care about, eg.
> "Win-7-Intel-32-DebugCompile" becomes "Win-7-VS2010-DebugCompile" to denote
that
> we're building on VS 2010, and we simply don't care whether it has Intel
> integrated graphics or what.  Another example:
> "OSX-10_8-MacMini-32-DebugCompile" --> "OSX-10_8-XCode4.6-32-DebugCompile". 
> Thoughts?
> 
>
https://codereview.chromium.org/13861012/diff/13001/master/master_builders_cf...
> File master/master_builders_cfg.py (right):
> 
>
https://codereview.chromium.org/13861012/diff/13001/master/master_builders_cf...
> master/master_builders_cfg.py:86: version=None,
> At Derek's suggestion, I excluded the Android version altogether.  The Android
> bots will be kept up-to-date, and we don't want to have to rename the
builders.

Added
https://docs.google.com/a/google.com/document/d/1BfTUBPJcnc7DD-G3DlOr0kmQsz0b...
to discuss what will need to happen when this change goes in.

[epoger, 2013-04-19 16:25:44]

https://codereview.chromium.org/13861012/diff/13001/master/master_builders_cf...
File master/master_builders_cfg.py (right):

https://codereview.chromium.org/13861012/diff/13001/master/master_builders_cf...
master/master_builders_cfg.py:61: hardware='ATI5770',
On 2013/04/17 17:50:15, borenet wrote:
> 1. 'hardware' vs 'gpu'.  The current set of builders doesn't make a
distinction.
>  Is that wrong?  In most cases we won't need two fields, but as we've
discussed,
> "MacMini" isn't descriptive enough.

If we just use a single "hardware" field, then that field has to communicate all
of the following:
1. GPU type
2. CPU type
3. motherboard / support chipset
4. memory / hard drive / other components

Personally, I think the best way to handle this info is to split out the GPU
type, and use a single hardware ID to imply the rest.  For example:
host=ShuttleA  gpu=ATI5770

I can imagine situations where new hardware revisions come into play, like we
can't order the exact same parts and now we have "ShuttleB" systems.  At least
we'll be able to distinguish between them if we see differences.

As for the MacMini, I renew my previous proposal to use the identifiers from
http://en.wikipedia.org/wiki/Mac_Mini#Specifications_3 ("Macmini4,1", etc.).  In
that case, the particular Macmini hardware flavor implies the GPU type.
host=Macmini4,1  gpu=builtin

And I guess a Shuttle machine without a GPU card installed is:
host=ShuttleA  gpu=builtin

https://codereview.chromium.org/13861012/diff/13001/master/slaves.cfg
File master/slaves.cfg (right):

https://codereview.chromium.org/13861012/diff/13001/master/slaves.cfg#newcode24
master/slaves.cfg:24: 'Android-x-NexusS-32-DebugCompile',
On 2013/04/17 17:50:15, borenet wrote:
> 2. There are 40 instances of "-x-", or 80 if you include the trybots.  All of
> them are OS versions for Android and ChromeOS.  I think that not including a
> version for these bots is the right thing to do, but I don't like the way it
> looks.

To avoid all these "-x-"es , we *could* just roll the OS version into the OS
name field, like so:

Ubuntu12, Android, ChromeOS, Win7, Win8

If you wanted to run on all Windows bots, I guess you could specify "all bots
whose OS field matches Win*", instead of "all bots whose OS field matches
Win"...

https://codereview.chromium.org/13861012/diff/13001/master/slaves.cfg#newcode62
master/slaves.cfg:62: 'Ubuntu-12-NoGPU-32-DebugCompile-Trybot',
These NoGPU builders are bugging me.  They are the ONE case in which our compile
bots seem to care about the GPU field.

https://codereview.chromium.org/13861012/diff/13001/master/slaves.cfg#newcode362
master/slaves.cfg:362: 'Ubuntu-12-ATI5770-32-Bench',
I think it would be better for the 32/64 field to be *after* the Debug/Release
field, because when there are numbers in two adjacent fields it's harder for a
human to parse the builder name.

In other words, if someone reads these two names out loud:
Ubuntu-12-ATI5770-32-Debug
Ubuntu-12-ATI5770-Debug-32
I think the second one is easier to understand.

https://codereview.chromium.org/13861012/diff/13001/master/slaves.cfg#newcode396
master/slaves.cfg:396: 'OSX-10_7-MacMini-32-Debug',
I think we should try to allow '.' in the version field (and thus, I guess, in
any field).  It's natural for this character to appear within a version number,
and it's not clear to me what would go wrong if we allowed its use.

https://codereview.chromium.org/13861012/diff/13001/master/slaves.cfg#newcode398
master/slaves.cfg:398: 'OSX-10_7-MacMini-64-Debug',
I still prefer "Mac" to "OSX".  I think it's clearer, and besides, it seems to
me that the "X" bit is already covered by version "10.*"

Ultimately, I would suggest names like this:

Mac10.7-MacMini-32-Debug

https://codereview.chromium.org/13861012/diff/13001/master/slaves.cfg#newcode559
master/slaves.cfg:559: 'OSX-10_7-MacMini-32-DebugCompile',
On 2013/04/17 17:50:15, borenet wrote:
> 3. General question about the compile bots: I don't particularly like the
> "CompileDebug" names, but I don't know of a better way. 

I think the way you have it set up now is reasonable; alternatively, we could
add another field which has one of these 6 values:
   Compile,    RunBench,    RunNonBench,
TryCompile, TryRunBench, TryRunNonBench

> Also of note is the
> fact that, for the most part, these builder names consist of the TARGET for
> which they build, rather than the platform on which they're building.  In some
> cases, we care about testing builds in different IDE versions, etc, but to say
> that our Mac compile bots, for example, are Mac Minis, is flat-out wrong in
most
> cases, even though from a practical standpoint it doesn't matter that they
> really run on Mac Pros.  A possible solution (which would add a LOT of
> complexity) is to split out the compile bots so that they can be named
> differently based on the aspects we care about, eg.
> "Win-7-Intel-32-DebugCompile" becomes "Win-7-VS2010-DebugCompile" to denote
that
> we're building on VS 2010, and we simply don't care whether it has Intel
> integrated graphics or what.  Another example:
> "OSX-10_8-MacMini-32-DebugCompile" --> "OSX-10_8-XCode4.6-32-DebugCompile". 
> Thoughts?

I can think of 3 choices here... of them, I think #1 (the way you already have
it) is best.


1. Stick with the current naming.  For compile bots, the hardware field
indicates the *target* hardware, not the hardware on which the compile was run.

    TryCompile-Win7-Shuttle-ATI5770-32-Debug
TryRunNonBench-Win7-Shuttle-ATI5770-32-Debug
   TryRunBench-Win7-Shuttle-ATI5770-32-Debug


2. Change the hardware/GPU fields used for compile bots:

    TryCompile-Win7-AnyHardware-AnyGPU-32-Debug
TryRunNonBench-Win7-Shuttle-ATI5770-32-Debug
   TryRunBench-Win7-Shuttle-ATI5770-32-Debug

Downsides:
A. this does not provide a place on the Compile bot to specify whether the code
was built in NoGPU mode
B. hard to see which compile bot corresponds to each run bot


3. We use a different schema for the 2 different bot types.  As an added bonus:
later on, that would allow us to list characteristics we care about *only* when
compiling, such as compiler version...

    TryCompile-Win7-VS2010-32-Debug
TryRunNonBench-Win7-Shuttle-ATI5770-32-Debug
   TryRunBench-Win7-Shuttle-ATI5770-32-Debug

Downsides are similar to those of option 2.

[borenet, 2013-04-22 16:29:55]

Uploaded patch set 4.  I have a new set of concerns:

1. The builder names are back to being very long (too long, IMO).  Can I include
less information?  The "model" field is almost never useful, but I can see how
it might be in the future.  GPUs on the Android devices are implied by the model
(as is the case with MacMini).

2. Compile bots.  The names are misleading at best, since they don't run on a
configuration matching the name.  Additionally, when we add more builder
configurations (I'd like at least two more GPU types on Windows), we'll be
wasting effort to have compile bots which target Intel, NVIDIA, and ATI cards,
when there's no difference in the binary we generate.  Instead, we should have
compile builders named by compiler and target (eg Win_7-VS2010-Release-32) so
that they can be chained and shared by multiple "runners".

https://codereview.chromium.org/13861012/diff/13001/master/master_builders_cf...
File master/master_builders_cfg.py (right):

https://codereview.chromium.org/13861012/diff/13001/master/master_builders_cf...
master/master_builders_cfg.py:61: hardware='ATI5770',
On 2013/04/19 16:25:44, epoger wrote:
> On 2013/04/17 17:50:15, borenet wrote:
> > 1. 'hardware' vs 'gpu'.  The current set of builders doesn't make a
> distinction.
> >  Is that wrong?  In most cases we won't need two fields, but as we've
> discussed,
> > "MacMini" isn't descriptive enough.
> 
> If we just use a single "hardware" field, then that field has to communicate
all
> of the following:
> 1. GPU type
> 2. CPU type
> 3. motherboard / support chipset
> 4. memory / hard drive / other components
> 
> Personally, I think the best way to handle this info is to split out the GPU
> type, and use a single hardware ID to imply the rest.  For example:
> host=ShuttleA  gpu=ATI5770
> 
> I can imagine situations where new hardware revisions come into play, like we
> can't order the exact same parts and now we have "ShuttleB" systems.  At least
> we'll be able to distinguish between them if we see differences.
> 
> As for the MacMini, I renew my previous proposal to use the identifiers from
> http://en.wikipedia.org/wiki/Mac_Mini#Specifications_3 ("Macmini4,1", etc.). 
In
> that case, the particular Macmini hardware flavor implies the GPU type.
> host=Macmini4,1  gpu=builtin
> 
> And I guess a Shuttle machine without a GPU card installed is:
> host=ShuttleA  gpu=builtin

Done.

https://codereview.chromium.org/13861012/diff/13001/master/slaves.cfg
File master/slaves.cfg (right):

https://codereview.chromium.org/13861012/diff/13001/master/slaves.cfg#newcode24
master/slaves.cfg:24: 'Android-x-NexusS-32-DebugCompile',
On 2013/04/19 16:25:44, epoger wrote:
> On 2013/04/17 17:50:15, borenet wrote:
> > 2. There are 40 instances of "-x-", or 80 if you include the trybots.  All
of
> > them are OS versions for Android and ChromeOS.  I think that not including a
> > version for these bots is the right thing to do, but I don't like the way it
> > looks.
> 
> To avoid all these "-x-"es , we *could* just roll the OS version into the OS
> name field, like so:
> 
> Ubuntu12, Android, ChromeOS, Win7, Win8
> 
> If you wanted to run on all Windows bots, I guess you could specify "all bots
> whose OS field matches Win*", instead of "all bots whose OS field matches
> Win"...

I think this is a good idea.  We could also optionally enforce that the OS name
and version (if it exists) are separated with an underscore, eg. Ubuntu_12-xyz,
so that it's still easily parseable into two fields.

https://codereview.chromium.org/13861012/diff/13001/master/slaves.cfg#newcode62
master/slaves.cfg:62: 'Ubuntu-12-NoGPU-32-DebugCompile-Trybot',
On 2013/04/19 16:25:44, epoger wrote:
> These NoGPU builders are bugging me.  They are the ONE case in which our
compile
> bots seem to care about the GPU field.

Agreed.  And in that case, it's a build configuration, NOT a hardware spec.  I
guess I'll put it in the GPU field, even though it's not an exact fit.

https://codereview.chromium.org/13861012/diff/13001/master/slaves.cfg#newcode362
master/slaves.cfg:362: 'Ubuntu-12-ATI5770-32-Bench',
On 2013/04/19 16:25:44, epoger wrote:
> I think it would be better for the 32/64 field to be *after* the Debug/Release
> field, because when there are numbers in two adjacent fields it's harder for a
> human to parse the builder name.
> 
> In other words, if someone reads these two names out loud:
> Ubuntu-12-ATI5770-32-Debug
> Ubuntu-12-ATI5770-Debug-32
> I think the second one is easier to understand.

Done.  However, it comes *before* extra_config, so that that field is always
last.

https://codereview.chromium.org/13861012/diff/13001/master/slaves.cfg#newcode396
master/slaves.cfg:396: 'OSX-10_7-MacMini-32-Debug',
On 2013/04/19 16:25:44, epoger wrote:
> I think we should try to allow '.' in the version field (and thus, I guess, in
> any field).  It's natural for this character to appear within a version
number,
> and it's not clear to me what would go wrong if we allowed its use.

Done.

https://codereview.chromium.org/13861012/diff/13001/master/slaves.cfg#newcode398
master/slaves.cfg:398: 'OSX-10_7-MacMini-64-Debug',
On 2013/04/19 16:25:44, epoger wrote:
> I still prefer "Mac" to "OSX".  I think it's clearer, and besides, it seems to
> me that the "X" bit is already covered by version "10.*"
> 
> Ultimately, I would suggest names like this:
> 
> Mac10.7-MacMini-32-Debug

Done.

https://codereview.chromium.org/13861012/diff/13001/master/slaves.cfg#newcode559
master/slaves.cfg:559: 'OSX-10_7-MacMini-32-DebugCompile',
On 2013/04/19 16:25:44, epoger wrote:
> On 2013/04/17 17:50:15, borenet wrote:
> > 3. General question about the compile bots: I don't particularly like the
> > "CompileDebug" names, but I don't know of a better way. 
> 
> I think the way you have it set up now is reasonable; alternatively, we could
> add another field which has one of these 6 values:
>    Compile,    RunBench,    RunNonBench,
> TryCompile, TryRunBench, TryRunNonBench
> 
> > Also of note is the
> > fact that, for the most part, these builder names consist of the TARGET for
> > which they build, rather than the platform on which they're building.  In
some
> > cases, we care about testing builds in different IDE versions, etc, but to
say
> > that our Mac compile bots, for example, are Mac Minis, is flat-out wrong in
> most
> > cases, even though from a practical standpoint it doesn't matter that they
> > really run on Mac Pros.  A possible solution (which would add a LOT of
> > complexity) is to split out the compile bots so that they can be named
> > differently based on the aspects we care about, eg.
> > "Win-7-Intel-32-DebugCompile" becomes "Win-7-VS2010-DebugCompile" to denote
> that
> > we're building on VS 2010, and we simply don't care whether it has Intel
> > integrated graphics or what.  Another example:
> > "OSX-10_8-MacMini-32-DebugCompile" --> "OSX-10_8-XCode4.6-32-DebugCompile". 
> > Thoughts?
> 
> I can think of 3 choices here... of them, I think #1 (the way you already have
> it) is best.
> 
> 
> 1. Stick with the current naming.  For compile bots, the hardware field
> indicates the *target* hardware, not the hardware on which the compile was
run.
> 
>     TryCompile-Win7-Shuttle-ATI5770-32-Debug
> TryRunNonBench-Win7-Shuttle-ATI5770-32-Debug
>    TryRunBench-Win7-Shuttle-ATI5770-32-Debug
> 
> 
> 2. Change the hardware/GPU fields used for compile bots:
> 
>     TryCompile-Win7-AnyHardware-AnyGPU-32-Debug
> TryRunNonBench-Win7-Shuttle-ATI5770-32-Debug
>    TryRunBench-Win7-Shuttle-ATI5770-32-Debug
> 
> Downsides:
> A. this does not provide a place on the Compile bot to specify whether the
code
> was built in NoGPU mode
> B. hard to see which compile bot corresponds to each run bot
> 
> 
> 3. We use a different schema for the 2 different bot types.  As an added
bonus:
> later on, that would allow us to list characteristics we care about *only*
when
> compiling, such as compiler version...
> 
>     TryCompile-Win7-VS2010-32-Debug
> TryRunNonBench-Win7-Shuttle-ATI5770-32-Debug
>    TryRunBench-Win7-Shuttle-ATI5770-32-Debug
> 
> Downsides are similar to those of option 2.

I will keep it as-is for now, but I think we'll need to separate out the compile
builders in the near future.

[rmistry, 2013-04-22 18:58:20]

https://codereview.chromium.org/13861012/diff/23001/master/slaves.cfg
File master/slaves.cfg (right):

https://codereview.chromium.org/13861012/diff/23001/master/slaves.cfg#newcode316
master/slaves.cfg:316: 'Mac_10.6-MacMini4,1-GeForce320M-Debug-32',
Eric shared the current names with me at
http://nautilus.cnc.corp.google.com:10125/builders

The comments I had were:
* The underscore in OS_Version is not very consistent with the rest of the
string, but Eric explained that it would make it easier to split the OS and
Version if we ever need to, this makes sense. Alternatively, we could remove the
underscore and make it look like Mac10.6-...
  This will probably not make it harder to search in the dashboard if we only
search for substrings. Either way I do not have a strong preference and I
understand the opposing argument.

* Regarding the ',' in MacMini4,1 I prefer if this was a '.'. I understand the
motivation to use the model name as specified by the vendor but we can always
use our own mapping of characters. Also, if a model name contained '-' then we
would not use it and would want to substitute something else in its place. We
could be consistent here and say any non alphanumeric character will be
substituted with a '.'.

* Since it is not useful to have the GPU specified for compile builders, that
section for the compile builders could stand for the compiler. Maybe we can
establish the rule that it stands for GPU *except* for compile builders.

* I also recommended that instead of '-ReleaseCompile-64' we use either
'-CompileRelease-64' or '-Release-64-Compile', it makes it slightly easier to
read but maybe this is a personal preference.

[borenet, 2013-04-22 19:32:44]

On 2013/04/22 18:58:20, rmistry wrote:
> https://codereview.chromium.org/13861012/diff/23001/master/slaves.cfg
> File master/slaves.cfg (right):
> 
>
https://codereview.chromium.org/13861012/diff/23001/master/slaves.cfg#newcode316
> master/slaves.cfg:316: 'Mac_10.6-MacMini4,1-GeForce320M-Debug-32',
> Eric shared the current names with me at
> http://nautilus.cnc.corp.google.com:10125/builders
> 
> The comments I had were:
> * The underscore in OS_Version is not very consistent with the rest of the
> string, but Eric explained that it would make it easier to split the OS and
> Version if we ever need to, this makes sense. Alternatively, we could remove
the
> underscore and make it look like Mac10.6-...
>   This will probably not make it harder to search in the dashboard if we only
> search for substrings. Either way I do not have a strong preference and I
> understand the opposing argument.
> 

I'm okay with removing the underscores.  Maybe this comes down to whether Ben
thinks he'll need to do any separation of OS and version, with the understanding
that some builders won't have an OS version.

> * Regarding the ',' in MacMini4,1 I prefer if this was a '.'. I understand the
> motivation to use the model name as specified by the vendor but we can always
> use our own mapping of characters. Also, if a model name contained '-' then we
> would not use it and would want to substitute something else in its place. We
> could be consistent here and say any non alphanumeric character will be
> substituted with a '.'.
> 

I see where you're coming from.  I get queasy feelings just having the '.' in
the OS version.  However, neither seems to be causing problems.  Let's see how
the others feel.

> * Since it is not useful to have the GPU specified for compile builders, that
> section for the compile builders could stand for the compiler. Maybe we can
> establish the rule that it stands for GPU *except* for compile builders.
> 

The more I think about this, the more strongly I feel that the compile builders
should be entirely separate in terms of builder configuration and name.  The
compile builders care about the OS and version, compiler used, and the target
platform (which does NOT include the GPU).  See my comment above for more
detail.

> * I also recommended that instead of '-ReleaseCompile-64' we use either
> '-CompileRelease-64' or '-Release-64-Compile', it makes it slightly easier to
> read but maybe this is a personal preference.

I can do this in the short term, as I agree that it is more readable.

[borenet, 2013-04-24 15:03:30]

On 2013/04/22 19:32:44, borenet wrote:
> On 2013/04/22 18:58:20, rmistry wrote:
> > https://codereview.chromium.org/13861012/diff/23001/master/slaves.cfg
> > File master/slaves.cfg (right):
> > 
> >
>
https://codereview.chromium.org/13861012/diff/23001/master/slaves.cfg#newcode316
> > master/slaves.cfg:316: 'Mac_10.6-MacMini4,1-GeForce320M-Debug-32',
> > Eric shared the current names with me at
> > http://nautilus.cnc.corp.google.com:10125/builders
> > 
> > The comments I had were:
> > * The underscore in OS_Version is not very consistent with the rest of the
> > string, but Eric explained that it would make it easier to split the OS and
> > Version if we ever need to, this makes sense. Alternatively, we could remove
> the
> > underscore and make it look like Mac10.6-...
> >   This will probably not make it harder to search in the dashboard if we
only
> > search for substrings. Either way I do not have a strong preference and I
> > understand the opposing argument.
> > 
> 
> I'm okay with removing the underscores.  Maybe this comes down to whether Ben
> thinks he'll need to do any separation of OS and version, with the
understanding
> that some builders won't have an OS version.
> 
> > * Regarding the ',' in MacMini4,1 I prefer if this was a '.'. I understand
the
> > motivation to use the model name as specified by the vendor but we can
always
> > use our own mapping of characters. Also, if a model name contained '-' then
we
> > would not use it and would want to substitute something else in its place.
We
> > could be consistent here and say any non alphanumeric character will be
> > substituted with a '.'.
> > 
> 
> I see where you're coming from.  I get queasy feelings just having the '.' in
> the OS version.  However, neither seems to be causing problems.  Let's see how
> the others feel.
> 
> > * Since it is not useful to have the GPU specified for compile builders,
that
> > section for the compile builders could stand for the compiler. Maybe we can
> > establish the rule that it stands for GPU *except* for compile builders.
> > 
> 
> The more I think about this, the more strongly I feel that the compile
builders
> should be entirely separate in terms of builder configuration and name.  The
> compile builders care about the OS and version, compiler used, and the target
> platform (which does NOT include the GPU).  See my comment above for more
> detail.
> 
> > * I also recommended that instead of '-ReleaseCompile-64' we use either
> > '-CompileRelease-64' or '-Release-64-Compile', it makes it slightly easier
to
> > read but maybe this is a personal preference.
> 
> I can do this in the short term, as I agree that it is more readable.

I uploaded an alternate approach here: https://codereview.chromium.org/14475006/

[borenet, 2013-04-24 15:55:16]

> I uploaded an alternate approach here:
https://codereview.chromium.org/14475006/

Based on live discussion, I'm closing this in favor of the aforementioned
alternate approach.