shans / chromez Goto Github PK

For tracking whether we are resolving bugs promptly, it is useful to know how long the bug has been in a given component (as opposed to how long the bug has been open, for example if the bug has been redirected from another component). It is not clear how to retrieve this information; it may be necessary to parse the full list of comments on the bug.

We have sort-of an 80-characters limit on CL issue naming (a header)
Moreover, many CL names start with the same prefix, like "Blink Compositor Animations: Unify Cubic*"
They are hard to distinguish.

Please, make that CL list element wider.

Design doc:
https://docs.google.com/document/d/18Hu0Tt1L0EwEnlRlwTY0rdhtXwsEDPJFjBETJAgLyG8/edit#

Local timezone should vary based on location so it because relative rather than absolute for a geographically dispersed team.

For example, for the cz-clock-dash the code does;

    Polymer({
      is: 'cz-clock-dash',

      properties: {
        timezones: {
          type: 'Object',
          notify: true,
          value: function() { return []; }
        }
      },

However, if you leave the "timezone" out of the config.json you end up with the following error on the console;

cz-clock-dash.html:87 Uncaught TypeError: Cannot read property 'forEach' of undefinedPolymer.mutateTimeString @ cz-clock-dash.html:87
Polymer.attached @ cz-clock-dash.html:78
Polymer.Base._addFeature._invokeBehavior @ polymer-micro.html:414
Polymer.Base._addFeature._doBehavior @ polymer-micro.html:409
(anonymous function) @ polymer-micro.html:212
Polymer.RenderStatus.whenReady @ polymer-micro.html:107
Polymer.Base.attachedCallback @ polymer-micro.html:210
Polymer.Base._addFeature.attachedCallback @ polymer-mini.html:105
(anonymous function) @ (index):73l.onload @ polymer.html:1333

Which comes from

      mutateTimeString: function() {
        this.timezones.forEach((timezone, idx) => this.set('timezones.' + idx + '.data', this.currentTimeDay(timezone)));
        this.async(() => this.mutateTimeString(), 1000);
      },

I don't understand polymer to know what is going wrong here. I would have thought that the value method should mean it ends up with a default of an empty list and https://www.polymer-project.org/1.0/docs/devguide/properties kinds of indicates that should be the case?

@shans @dstockwell - Help?

The only way to force a refresh at the moment seems to be to turn the dashboard off and on again.

paper-icon and paper-badge need iron-icon, but don't list it as a dependency.

You might want to add this to bower.json: (I'd do a pull request, but my authenticator died. Don't ask)

"iron-icon": "PolymerElements/iron-icon#~1.0.0",

The above shows the review as 'Shane's review', but the actual review (https://codereview.chromium.org/2215203002) has three reviewers on it.

Should that make it 'Shane's shared reviews'?

Attempted to fix this but ran into a Polymer bug where the <template is='dom-repeat' items={{views}}> doesn't update when views.length becomes 1 inside columnsChanged().

Next step is to try updating Polymer or create a work around.

It would be useful to have either
a) a timestamp on the bottom of each card showing when its data was last updated, or
b) a separate card which displays the time that important queries were last updated.

Requests sent to monorail via the redirect in redirect.py return at most 100 issues. Checking https://monorail-prod.appspot.com/_ah/api/discovery/v1/apis/monorail/v1/rest I think we need to add maxResults and/or startIndex parameters to increase the number of issues returned on the first request or page through results in multiple requests.

At the moment, component-dash has to create multiple cards internally, because the configuration file is confined to a simple list of dashboards and globally named configurations. This means that there's no convenient way to request a list of component-dashes with different configurations.

However, multiple internal cards don't flex wrap properly, and there's no convenient way to break the component isolation barrier to make this work.

If we let the dashboard list take a function syntax instead, e.g.

"dashes": [
    "cz-component-dash(Blink>Animation)",
    "cz-component-dash(Internals>Compositing>Animation)",
    ...
]

Then the component dash can be given its name as part of its construction, and use it to index appropriately into the configuration. Later we can even make a lot of this automatic if we want.

the redirect to monorail issues only allows queries to can='open'. It would be really nice if reasonable queries for closed issues also worked. e.g. For tracking recent progress. How about parsing another value out of an incoming can parameter?

This would be fun.

More reviews = bigger node
More reviews for X = darker (directed?) edge to X

May or may not disregard old data.

I have a 1920x1080 screen (normal DPI), so I expect to see all of the content without scrolling and if not, at least to have an option to scroll. But currently, the left part of the page is hidden, it does not fit the screen and there are no scroll bars.