Change UMA proto product field to be an int32.

components/metrics/proto/chrome_user_metrics_extension.proto

Index: components/metrics/proto/chrome_user_metrics_extension.proto
diff --git a/components/metrics/proto/chrome_user_metrics_extension.proto b/components/metrics/proto/chrome_user_metrics_extension.proto
index 7efa5b4c7dbe309b01c81a11344f52544b05e8fa..b4267f48df8904ea3752b45c789bb8cd75bcefd6 100644
--- a/components/metrics/proto/chrome_user_metrics_extension.proto
+++ b/components/metrics/proto/chrome_user_metrics_extension.proto
@@ -25,9 +25,13 @@ message ChromeUserMetricsExtension {
     // Google Chrome product family.
     CHROME = 0;
   }
-  // The product corresponding to this log. Note: The default value is Chrome,
-  // so Chrome products will not transmit this field.
-  optional Product product = 10 [default = CHROME];
+  // The product corresponding to this log. The field type is int32 instead of
+  // Product so that downstream users of the Chromium metrics component can
+  // introduce products without needing to make changes to the Chromium code
+  // (though they still need to add the new product to the server-side enum).
+  // Note: The default value is Chrome, so Chrome products will not transmit
+  // this field.
+  optional int32 product = 10 [default = 0];

[Ilya Sherman, 2014/09/25 18:29:55]

Are you sure that we want a signed int rather than an unsigned int?  (I don't
remember how much of a difference it makes, but worth thinking about.)

[Alexei Svitkine (slow), 2014/09/26 16:51:09]

Enums can definitely be negative in protos and I'm pretty sure int32 is the
exact match for the underlying type for the enum, so I think int32 is the right
thing to use here (no need for signed/unsigned conversion when assigning enum
constants to the field).

 
   // The id of the client install that generated these events.
   //