Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
138413004:
Add AUTHORS file for copyright tracking (Closed)
|
Created:
6 years, 11 months ago by hcm Modified:
6 years, 11 months ago CC:
skia-review_googlegroups.com Base URL:
https://skia.googlesource.com/skia.git@master Visibility:
Public. |
DescriptionAdd AUTHORS file for copyright tracking
BUG=skia:
Committed: http://code.google.com/p/skia/source/detail?r=13117
Patch Set 1 #
Total comments: 2
Messages
Total messages: 15 (0 generated)
Adding AUTHORS file per guidelines related to CLA and keeping track of all code contributors. Will be referencing file in documentation.
https://codereview.chromium.org/138413004/diff/1/AUTHORS File AUTHORS (right): https://codereview.chromium.org/138413004/diff/1/AUTHORS#newcode10 AUTHORS:10: Intel Maybe this should be @intel.com ? Actually if we want to automate this at a later date it would be helpful if it was machine readable also. How about an email address, or email address-like thing followed by a space and then a free form name? tfarina@chromium.org Thiago Fransosi Farina @intel.com Intel @google.com Google Inc.
Out of curiosity, what is the motivation behind this CL? If we store this file in Google Storage with world readable permissions I could read it from the CQ to determine if an external contributor of Skia has signed the CLA (till go/signcla is ready). Any potential docs could point to the file as well, since Google Storage has an HTTP interface. https://codereview.chromium.org/138413004/diff/1/AUTHORS File AUTHORS (right): https://codereview.chromium.org/138413004/diff/1/AUTHORS#newcode10 AUTHORS:10: Intel On 2014/01/15 21:34:05, jcgregorio wrote: > Maybe this should be @intel.com ? > > Actually if we want to automate this at a later date it would be helpful if it > was machine readable also. How about an email address, or email address-like > thing followed by a space and then a free form name? > > mailto:tfarina@chromium.org Thiago Fransosi Farina > @intel.com Intel > @google.com Google Inc. For being easily automatable by systems like CQ I would prefer if this was in JSON. Maybe it should contain email: "intel.com", friendly_string (or a better name): "Intel Inc" email: "tfarina@chromium.org", friendly_string (or a better name): "Thiago ..."
On 2014/01/15 22:28:53, rmistry wrote: > Out of curiosity, what is the motivation behind this CL? Following up with my own question, if the motivation is only to reference it in docs then Google Storage might not be a bad place for this. WDYT Joe? > If we store this file in Google Storage with world readable permissions I could > read it from the CQ to determine if an external contributor of Skia has signed > the CLA (till go/signcla is ready). > Any potential docs could point to the file as well, since Google Storage has an > HTTP interface. > > https://codereview.chromium.org/138413004/diff/1/AUTHORS > File AUTHORS (right): > > https://codereview.chromium.org/138413004/diff/1/AUTHORS#newcode10 > AUTHORS:10: Intel > On 2014/01/15 21:34:05, jcgregorio wrote: > > Maybe this should be @intel.com ? > > > > Actually if we want to automate this at a later date it would be helpful if it > > was machine readable also. How about an email address, or email address-like > > thing followed by a space and then a free form name? > > > > mailto:tfarina@chromium.org Thiago Fransosi Farina > > @intel.com Intel > > @google.com Google Inc. > > For being easily automatable by systems like CQ I would prefer if this was in > JSON. > Maybe it should contain > email: "intel.com", friendly_string (or a better name): "Intel Inc" > email: "tfarina@chromium.org", friendly_string (or a better name): "Thiago ..."
On 2014/01/15 22:30:59, rmistry wrote: > On 2014/01/15 22:28:53, rmistry wrote: > > Out of curiosity, what is the motivation behind this CL? > > Following up with my own question, if the motivation is only to reference it in > docs then Google Storage might not be a bad place for this. WDYT Joe? > > > If we store this file in Google Storage with world readable permissions I > could > > read it from the CQ to determine if an external contributor of Skia has signed > > the CLA (till go/signcla is ready). > > Any potential docs could point to the file as well, since Google Storage has > an > > HTTP interface. > > > > https://codereview.chromium.org/138413004/diff/1/AUTHORS > > File AUTHORS (right): > > > > https://codereview.chromium.org/138413004/diff/1/AUTHORS#newcode10 > > AUTHORS:10: Intel > > On 2014/01/15 21:34:05, jcgregorio wrote: > > > Maybe this should be @intel.com ? > > > > > > Actually if we want to automate this at a later date it would be helpful if > it > > > was machine readable also. How about an email address, or email address-like > > > thing followed by a space and then a free form name? > > > > > > mailto:tfarina@chromium.org Thiago Fransosi Farina > > > @intel.com Intel > > > @google.com Google Inc. > > > > For being easily automatable by systems like CQ I would prefer if this was in > > JSON. > > Maybe it should contain > > email: "intel.com", friendly_string (or a better name): "Intel Inc" > > email: "tfarina@chromium.org", friendly_string (or a better name): "Thiago > ..." Any docs we put in our repo get free versioning. We have other reasons (namely, buildbot master trampoline link) to want to serve our repo over HTTP at head, so that should come for free then too.
On 2014/01/15 22:38:33, mtklein wrote: > On 2014/01/15 22:30:59, rmistry wrote: > > On 2014/01/15 22:28:53, rmistry wrote: > > > Out of curiosity, what is the motivation behind this CL? > > > > Following up with my own question, if the motivation is only to reference it > in > > docs then Google Storage might not be a bad place for this. WDYT Joe? > > > > > If we store this file in Google Storage with world readable permissions I > > could > > > read it from the CQ to determine if an external contributor of Skia has > signed > > > the CLA (till go/signcla is ready). > > > Any potential docs could point to the file as well, since Google Storage has > > an > > > HTTP interface. > > > > > > https://codereview.chromium.org/138413004/diff/1/AUTHORS > > > File AUTHORS (right): > > > > > > https://codereview.chromium.org/138413004/diff/1/AUTHORS#newcode10 > > > AUTHORS:10: Intel > > > On 2014/01/15 21:34:05, jcgregorio wrote: > > > > Maybe this should be @intel.com ? > > > > > > > > Actually if we want to automate this at a later date it would be helpful > if > > it > > > > was machine readable also. How about an email address, or email > address-like > > > > thing followed by a space and then a free form name? > > > > > > > > mailto:tfarina@chromium.org Thiago Fransosi Farina > > > > @intel.com Intel > > > > @google.com Google Inc. > > > > > > For being easily automatable by systems like CQ I would prefer if this was > in > > > JSON. > > > Maybe it should contain > > > email: "intel.com", friendly_string (or a better name): "Intel Inc" > > > email: "tfarina@chromium.org", friendly_string (or a better name): "Thiago > > ..." > > Any docs we put in our repo get free versioning. We have other reasons (namely, > buildbot master trampoline link) to want to serve our repo over HTTP at head, so > that should come for free then too. googlesource does not serve HTTP, unless you are talking about github (which would work). Yes the benefit is versioning, though I am not sure it matters that much with this file, in Google Storage I can give access only to hcm@ and reed@ and the JSON could include the user and the reason.
On 2014/01/15 22:45:22, rmistry wrote: > On 2014/01/15 22:38:33, mtklein wrote: > > On 2014/01/15 22:30:59, rmistry wrote: > > > On 2014/01/15 22:28:53, rmistry wrote: > > > > Out of curiosity, what is the motivation behind this CL? > > > > > > Following up with my own question, if the motivation is only to reference it > > in > > > docs then Google Storage might not be a bad place for this. WDYT Joe? > > > > > > > If we store this file in Google Storage with world readable permissions I > > > could > > > > read it from the CQ to determine if an external contributor of Skia has > > signed > > > > the CLA (till go/signcla is ready). > > > > Any potential docs could point to the file as well, since Google Storage > has > > > an > > > > HTTP interface. > > > > > > > > https://codereview.chromium.org/138413004/diff/1/AUTHORS > > > > File AUTHORS (right): > > > > > > > > https://codereview.chromium.org/138413004/diff/1/AUTHORS#newcode10 > > > > AUTHORS:10: Intel > > > > On 2014/01/15 21:34:05, jcgregorio wrote: > > > > > Maybe this should be @intel.com ? > > > > > > > > > > Actually if we want to automate this at a later date it would be helpful > > if > > > it > > > > > was machine readable also. How about an email address, or email > > address-like > > > > > thing followed by a space and then a free form name? > > > > > > > > > > mailto:tfarina@chromium.org Thiago Fransosi Farina > > > > > @intel.com Intel > > > > > @google.com Google Inc. > > > > > > > > For being easily automatable by systems like CQ I would prefer if this was > > in > > > > JSON. > > > > Maybe it should contain > > > > email: "intel.com", friendly_string (or a better name): "Intel Inc" > > > > email: "tfarina@chromium.org", friendly_string (or a better name): "Thiago > > > ..." > > > > Any docs we put in our repo get free versioning. We have other reasons > (namely, > > buildbot master trampoline link) to want to serve our repo over HTTP at head, > so > > that should come for free then too. > > googlesource does not serve HTTP, unless you are talking about github (which > would work). > Yes the benefit is versioning, though I am not sure it matters that much with > this file, in Google Storage I can give access only to hcm@ and reed@ and the > JSON could include the user and the reason. Or maybe github does not work for this: https://code.google.com/p/skia/issues/detail?id=2048 Google Storage serves HTTP just file: https://storage.cloud.google.com/chromium-skia-gm/telemetry/tryserver-outputs...
On 2014/01/15 22:48:35, rmistry wrote: > On 2014/01/15 22:45:22, rmistry wrote: > > On 2014/01/15 22:38:33, mtklein wrote: > > > On 2014/01/15 22:30:59, rmistry wrote: > > > > On 2014/01/15 22:28:53, rmistry wrote: > > > > > Out of curiosity, what is the motivation behind this CL? > > > > > > > > Following up with my own question, if the motivation is only to reference > it > > > in > > > > docs then Google Storage might not be a bad place for this. WDYT Joe? > > > > > > > > > If we store this file in Google Storage with world readable permissions > I > > > > could > > > > > read it from the CQ to determine if an external contributor of Skia has > > > signed > > > > > the CLA (till go/signcla is ready). > > > > > Any potential docs could point to the file as well, since Google Storage > > has > > > > an > > > > > HTTP interface. > > > > > > > > > > https://codereview.chromium.org/138413004/diff/1/AUTHORS > > > > > File AUTHORS (right): > > > > > > > > > > https://codereview.chromium.org/138413004/diff/1/AUTHORS#newcode10 > > > > > AUTHORS:10: Intel > > > > > On 2014/01/15 21:34:05, jcgregorio wrote: > > > > > > Maybe this should be @intel.com ? > > > > > > > > > > > > Actually if we want to automate this at a later date it would be > helpful > > > if > > > > it > > > > > > was machine readable also. How about an email address, or email > > > address-like > > > > > > thing followed by a space and then a free form name? > > > > > > > > > > > > mailto:tfarina@chromium.org Thiago Fransosi Farina > > > > > > @intel.com Intel > > > > > > @google.com Google Inc. > > > > > > > > > > For being easily automatable by systems like CQ I would prefer if this > was > > > in > > > > > JSON. > > > > > Maybe it should contain > > > > > email: "intel.com", friendly_string (or a better name): "Intel Inc" > > > > > email: "tfarina@chromium.org", friendly_string (or a better name): > "Thiago > > > > ..." > > > > > > Any docs we put in our repo get free versioning. We have other reasons > > (namely, > > > buildbot master trampoline link) to want to serve our repo over HTTP at > head, > > so > > > that should come for free then too. > > > > googlesource does not serve HTTP, unless you are talking about github (which > > would work). > > Yes the benefit is versioning, though I am not sure it matters that much with > > this file, in Google Storage I can give access only to hcm@ and reed@ and the > > JSON could include the user and the reason. > > Or maybe github does not work for this: > https://code.google.com/p/skia/issues/detail?id=2048 > Google Storage serves HTTP just file: > https://storage.cloud.google.com/chromium-skia-gm/telemetry/tryserver-outputs... Our default position should be to put things in the main repo and use Google Storage only when it's a burden to force everyone to download the history of that file.
On 2014/01/15 22:49:38, mtklein wrote: > On 2014/01/15 22:48:35, rmistry wrote: > > On 2014/01/15 22:45:22, rmistry wrote: > > > On 2014/01/15 22:38:33, mtklein wrote: > > > > On 2014/01/15 22:30:59, rmistry wrote: > > > > > On 2014/01/15 22:28:53, rmistry wrote: > > > > > > Out of curiosity, what is the motivation behind this CL? > > > > > > > > > > Following up with my own question, if the motivation is only to > reference > > it > > > > in > > > > > docs then Google Storage might not be a bad place for this. WDYT Joe? > > > > > > > > > > > If we store this file in Google Storage with world readable > permissions > > I > > > > > could > > > > > > read it from the CQ to determine if an external contributor of Skia > has > > > > signed > > > > > > the CLA (till go/signcla is ready). > > > > > > Any potential docs could point to the file as well, since Google > Storage > > > has > > > > > an > > > > > > HTTP interface. > > > > > > > > > > > > https://codereview.chromium.org/138413004/diff/1/AUTHORS > > > > > > File AUTHORS (right): > > > > > > > > > > > > https://codereview.chromium.org/138413004/diff/1/AUTHORS#newcode10 > > > > > > AUTHORS:10: Intel > > > > > > On 2014/01/15 21:34:05, jcgregorio wrote: > > > > > > > Maybe this should be @intel.com ? > > > > > > > > > > > > > > Actually if we want to automate this at a later date it would be > > helpful > > > > if > > > > > it > > > > > > > was machine readable also. How about an email address, or email > > > > address-like > > > > > > > thing followed by a space and then a free form name? > > > > > > > > > > > > > > mailto:tfarina@chromium.org Thiago Fransosi Farina > > > > > > > @intel.com Intel > > > > > > > @google.com Google Inc. > > > > > > > > > > > > For being easily automatable by systems like CQ I would prefer if this > > was > > > > in > > > > > > JSON. > > > > > > Maybe it should contain > > > > > > email: "intel.com", friendly_string (or a better name): "Intel Inc" > > > > > > email: "tfarina@chromium.org", friendly_string (or a better name): > > "Thiago > > > > > ..." > > > > > > > > Any docs we put in our repo get free versioning. We have other reasons > > > (namely, > > > > buildbot master trampoline link) to want to serve our repo over HTTP at > > head, > > > so > > > > that should come for free then too. > > > > > > googlesource does not serve HTTP, unless you are talking about github (which > > > would work). > > > Yes the benefit is versioning, though I am not sure it matters that much > with > > > this file, in Google Storage I can give access only to hcm@ and reed@ and > the > > > JSON could include the user and the reason. > > > > Or maybe github does not work for this: > > https://code.google.com/p/skia/issues/detail?id=2048 > > Google Storage serves HTTP just file: > > > https://storage.cloud.google.com/chromium-skia-gm/telemetry/tryserver-outputs... > > Our default position should be to put things in the main repo and use Google > Storage only when it's a burden to force everyone to download the history of > that file. That makes it very difficult for automated systems since googlesource does not serve HTTP. If they did then it is a different story, I cannot from the CQ parse HTML tags to get the file content. Github solves this problem, lets see what the conclusion of https://code.google.com/p/skia/issues/detail?id=2048 is.
On 2014/01/15 21:34:05, jcgregorio wrote: > https://codereview.chromium.org/138413004/diff/1/AUTHORS > File AUTHORS (right): > > https://codereview.chromium.org/138413004/diff/1/AUTHORS#newcode10 > AUTHORS:10: Intel > Maybe this should be @intel.com ? The Google guidelines and policies used by most other products are that a corporate entry does not require an email address... that's why it just says the company name. If we want to do something with a delimiter, I did see one other project doing so, but it was not a hard requirement. > > Actually if we want to automate this at a later date it would be helpful if it > was machine readable also. How about an email address, or email address-like > thing followed by a space and then a free form name? > > mailto:tfarina@chromium.org Thiago Fransosi Farina > @intel.com Intel > @google.com Google Inc. The formatting wasn't chosen by me but based on the template Google provides and that Chromium and all others I found are following linked here: https://sites.google.com/a/google.com/ospo/releasing/authors The whole process seems too manual though (including CLA checking via a huge excel file maintained for all products).
On 2014/01/15 22:59:11, rmistry wrote: > On 2014/01/15 22:49:38, mtklein wrote: > > On 2014/01/15 22:48:35, rmistry wrote: > > > On 2014/01/15 22:45:22, rmistry wrote: > > > > On 2014/01/15 22:38:33, mtklein wrote: > > > > > On 2014/01/15 22:30:59, rmistry wrote: > > > > > > On 2014/01/15 22:28:53, rmistry wrote: > > > > > > > Out of curiosity, what is the motivation behind this CL? > > > > > > > > > > > > Following up with my own question, if the motivation is only to > > reference > > > it > > > > > in > > > > > > docs then Google Storage might not be a bad place for this. WDYT Joe? > > > > > > > > > > > > > If we store this file in Google Storage with world readable > > permissions > > > I > > > > > > could > > > > > > > read it from the CQ to determine if an external contributor of Skia > > has > > > > > signed > > > > > > > the CLA (till go/signcla is ready). > > > > > > > Any potential docs could point to the file as well, since Google > > Storage > > > > has > > > > > > an > > > > > > > HTTP interface. > > > > > > > > > > > > > > https://codereview.chromium.org/138413004/diff/1/AUTHORS > > > > > > > File AUTHORS (right): > > > > > > > > > > > > > > https://codereview.chromium.org/138413004/diff/1/AUTHORS#newcode10 > > > > > > > AUTHORS:10: Intel > > > > > > > On 2014/01/15 21:34:05, jcgregorio wrote: > > > > > > > > Maybe this should be @intel.com ? > > > > > > > > > > > > > > > > Actually if we want to automate this at a later date it would be > > > helpful > > > > > if > > > > > > it > > > > > > > > was machine readable also. How about an email address, or email > > > > > address-like > > > > > > > > thing followed by a space and then a free form name? > > > > > > > > > > > > > > > > mailto:tfarina@chromium.org Thiago Fransosi Farina > > > > > > > > @intel.com Intel > > > > > > > > @google.com Google Inc. > > > > > > > > > > > > > > For being easily automatable by systems like CQ I would prefer if > this > > > was > > > > > in > > > > > > > JSON. > > > > > > > Maybe it should contain > > > > > > > email: "intel.com", friendly_string (or a better name): "Intel Inc" > > > > > > > email: "tfarina@chromium.org", friendly_string (or a better name): > > > "Thiago > > > > > > ..." > > > > > > > > > > Any docs we put in our repo get free versioning. We have other reasons > > > > (namely, > > > > > buildbot master trampoline link) to want to serve our repo over HTTP at > > > head, > > > > so > > > > > that should come for free then too. > > > > > > > > googlesource does not serve HTTP, unless you are talking about github > (which > > > > would work). > > > > Yes the benefit is versioning, though I am not sure it matters that much > > with > > > > this file, in Google Storage I can give access only to hcm@ and reed@ and > > the > > > > JSON could include the user and the reason. > > > > > > Or maybe github does not work for this: > > > https://code.google.com/p/skia/issues/detail?id=2048 > > > Google Storage serves HTTP just file: > > > > > > https://storage.cloud.google.com/chromium-skia-gm/telemetry/tryserver-outputs... > > > > Our default position should be to put things in the main repo and use Google > > Storage only when it's a burden to force everyone to download the history of > > that file. > > That makes it very difficult for automated systems since googlesource does not > serve HTTP. If they did then it is a different story, I cannot from the CQ parse > HTML tags to get the file content. > Github solves this problem, lets see what the conclusion of > https://code.google.com/p/skia/issues/detail?id=2048 is. I am fine holding off if we think we are on the verge of an automated solution. Was just trying to get us in compliance asap following the current structure Google has and that Chromium and the others are following. That process is to maintain a flat file of the format I submitted (though not sure if legal really cares or we can change it per some of the recommendations) and have authors add their names to the file as a part of their CL if they are not already listed.
On 2014/01/16 02:29:24, hcm wrote: > On 2014/01/15 22:59:11, rmistry wrote: > > On 2014/01/15 22:49:38, mtklein wrote: > > > On 2014/01/15 22:48:35, rmistry wrote: > > > > On 2014/01/15 22:45:22, rmistry wrote: > > > > > On 2014/01/15 22:38:33, mtklein wrote: > > > > > > On 2014/01/15 22:30:59, rmistry wrote: > > > > > > > On 2014/01/15 22:28:53, rmistry wrote: > > > > > > > > Out of curiosity, what is the motivation behind this CL? > > > > > > > > > > > > > > Following up with my own question, if the motivation is only to > > > reference > > > > it > > > > > > in > > > > > > > docs then Google Storage might not be a bad place for this. WDYT > Joe? > > > > > > > > > > > > > > > If we store this file in Google Storage with world readable > > > permissions > > > > I > > > > > > > could > > > > > > > > read it from the CQ to determine if an external contributor of > Skia > > > has > > > > > > signed > > > > > > > > the CLA (till go/signcla is ready). > > > > > > > > Any potential docs could point to the file as well, since Google > > > Storage > > > > > has > > > > > > > an > > > > > > > > HTTP interface. > > > > > > > > > > > > > > > > https://codereview.chromium.org/138413004/diff/1/AUTHORS > > > > > > > > File AUTHORS (right): > > > > > > > > > > > > > > > > https://codereview.chromium.org/138413004/diff/1/AUTHORS#newcode10 > > > > > > > > AUTHORS:10: Intel > > > > > > > > On 2014/01/15 21:34:05, jcgregorio wrote: > > > > > > > > > Maybe this should be @intel.com ? > > > > > > > > > > > > > > > > > > Actually if we want to automate this at a later date it would be > > > > helpful > > > > > > if > > > > > > > it > > > > > > > > > was machine readable also. How about an email address, or email > > > > > > address-like > > > > > > > > > thing followed by a space and then a free form name? > > > > > > > > > > > > > > > > > > mailto:tfarina@chromium.org Thiago Fransosi Farina > > > > > > > > > @intel.com Intel > > > > > > > > > @google.com Google Inc. > > > > > > > > > > > > > > > > For being easily automatable by systems like CQ I would prefer if > > this > > > > was > > > > > > in > > > > > > > > JSON. > > > > > > > > Maybe it should contain > > > > > > > > email: "intel.com", friendly_string (or a better name): "Intel > Inc" > > > > > > > > email: "tfarina@chromium.org", friendly_string (or a better name): > > > > "Thiago > > > > > > > ..." > > > > > > > > > > > > Any docs we put in our repo get free versioning. We have other > reasons > > > > > (namely, > > > > > > buildbot master trampoline link) to want to serve our repo over HTTP > at > > > > head, > > > > > so > > > > > > that should come for free then too. > > > > > > > > > > googlesource does not serve HTTP, unless you are talking about github > > (which > > > > > would work). > > > > > Yes the benefit is versioning, though I am not sure it matters that much > > > with > > > > > this file, in Google Storage I can give access only to hcm@ and reed@ > and > > > the > > > > > JSON could include the user and the reason. > > > > > > > > Or maybe github does not work for this: > > > > https://code.google.com/p/skia/issues/detail?id=2048 > > > > Google Storage serves HTTP just file: > > > > > > > > > > https://storage.cloud.google.com/chromium-skia-gm/telemetry/tryserver-outputs... > > > > > > Our default position should be to put things in the main repo and use Google > > > Storage only when it's a burden to force everyone to download the history of > > > that file. > > > > That makes it very difficult for automated systems since googlesource does not > > serve HTTP. If they did then it is a different story, I cannot from the CQ > parse > > HTML tags to get the file content. > > Github solves this problem, lets see what the conclusion of > > https://code.google.com/p/skia/issues/detail?id=2048 is. > > I am fine holding off if we think we are on the verge of an automated solution. > Was just trying to get us in compliance asap following the current structure > Google has and that Chromium and the others are following. That process is to > maintain a flat file of the format I submitted (though not sure if legal really > cares or we can change it per some of the recommendations) and have authors add > their names to the file as a part of their CL if they are not already listed. LGTM for this change because it makes sense to get something in while we figure out the mechanics of the automated solution. We should also find out from legal if the format matters (is JSON ok?) because if not then we will have to maintain two files (this one and the machine readable one).
CQ is trying da patch. Follow status at https://skia-tree-status.appspot.com/cq/hcm@google.com/138413004/1
On 2014/01/16 13:48:04, rmistry wrote: > On 2014/01/16 02:29:24, hcm wrote: > > On 2014/01/15 22:59:11, rmistry wrote: > > > On 2014/01/15 22:49:38, mtklein wrote: > > > > On 2014/01/15 22:48:35, rmistry wrote: > > > > > On 2014/01/15 22:45:22, rmistry wrote: > > > > > > On 2014/01/15 22:38:33, mtklein wrote: > > > > > > > On 2014/01/15 22:30:59, rmistry wrote: > > > > > > > > On 2014/01/15 22:28:53, rmistry wrote: > > > > > > > > > Out of curiosity, what is the motivation behind this CL? > > > > > > > > > > > > > > > > Following up with my own question, if the motivation is only to > > > > reference > > > > > it > > > > > > > in > > > > > > > > docs then Google Storage might not be a bad place for this. WDYT > > Joe? > > > > > > > > > > > > > > > > > If we store this file in Google Storage with world readable > > > > permissions > > > > > I > > > > > > > > could > > > > > > > > > read it from the CQ to determine if an external contributor of > > Skia > > > > has > > > > > > > signed > > > > > > > > > the CLA (till go/signcla is ready). > > > > > > > > > Any potential docs could point to the file as well, since Google > > > > Storage > > > > > > has > > > > > > > > an > > > > > > > > > HTTP interface. > > > > > > > > > > > > > > > > > > https://codereview.chromium.org/138413004/diff/1/AUTHORS > > > > > > > > > File AUTHORS (right): > > > > > > > > > > > > > > > > > > > https://codereview.chromium.org/138413004/diff/1/AUTHORS#newcode10 > > > > > > > > > AUTHORS:10: Intel > > > > > > > > > On 2014/01/15 21:34:05, jcgregorio wrote: > > > > > > > > > > Maybe this should be @intel.com ? > > > > > > > > > > > > > > > > > > > > Actually if we want to automate this at a later date it would > be > > > > > helpful > > > > > > > if > > > > > > > > it > > > > > > > > > > was machine readable also. How about an email address, or > email > > > > > > > address-like > > > > > > > > > > thing followed by a space and then a free form name? > > > > > > > > > > > > > > > > > > > > mailto:tfarina@chromium.org Thiago Fransosi Farina > > > > > > > > > > @intel.com Intel > > > > > > > > > > @google.com Google Inc. > > > > > > > > > > > > > > > > > > For being easily automatable by systems like CQ I would prefer > if > > > this > > > > > was > > > > > > > in > > > > > > > > > JSON. > > > > > > > > > Maybe it should contain > > > > > > > > > email: "intel.com", friendly_string (or a better name): "Intel > > Inc" > > > > > > > > > email: "tfarina@chromium.org", friendly_string (or a better > name): > > > > > "Thiago > > > > > > > > ..." > > > > > > > > > > > > > > Any docs we put in our repo get free versioning. We have other > > reasons > > > > > > (namely, > > > > > > > buildbot master trampoline link) to want to serve our repo over HTTP > > at > > > > > head, > > > > > > so > > > > > > > that should come for free then too. > > > > > > > > > > > > googlesource does not serve HTTP, unless you are talking about github > > > (which > > > > > > would work). > > > > > > Yes the benefit is versioning, though I am not sure it matters that > much > > > > with > > > > > > this file, in Google Storage I can give access only to hcm@ and reed@ > > and > > > > the > > > > > > JSON could include the user and the reason. > > > > > > > > > > Or maybe github does not work for this: > > > > > https://code.google.com/p/skia/issues/detail?id=2048 > > > > > Google Storage serves HTTP just file: > > > > > > > > > > > > > > > https://storage.cloud.google.com/chromium-skia-gm/telemetry/tryserver-outputs... > > > > > > > > Our default position should be to put things in the main repo and use > Google > > > > Storage only when it's a burden to force everyone to download the history > of > > > > that file. > > > > > > That makes it very difficult for automated systems since googlesource does > not > > > serve HTTP. If they did then it is a different story, I cannot from the CQ > > parse > > > HTML tags to get the file content. > > > Github solves this problem, lets see what the conclusion of > > > https://code.google.com/p/skia/issues/detail?id=2048 is. > > > > I am fine holding off if we think we are on the verge of an automated > solution. > > Was just trying to get us in compliance asap following the current structure > > Google has and that Chromium and the others are following. That process is to > > maintain a flat file of the format I submitted (though not sure if legal > really > > cares or we can change it per some of the recommendations) and have authors > add > > their names to the file as a part of their CL if they are not already listed. > > LGTM for this change because it makes sense to get something in while we figure > out the mechanics of the automated solution. > > We should also find out from legal if the format matters (is JSON ok?) because > if not then we will have to maintain two files (this one and the machine > readable one). Have a request in with Open Source Project Office to understand if there are hard requirements on formatting. Committing text file for now and will open issue to track development of machine readable file once we are automating the process.
Message was sent while issue was closed.
Change committed as 13117 |
