Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Support for disabled metrics #1048
This is for based on the work of @phauer in #1008. The set of disabled metrics is implemented in
referenced this pull request
Jan 30, 2017
changed the title from
[WIP] Support for disabled metrics
Support for disabled metrics
Feb 4, 2017
I don't like the inverted logic too. But I think it makes sense from the the user's perspective. The user reports some metrics to its time-series database and sees that some of them are useless, because he/she doesn't use them. The user wants to disable them. For instance,
Is this only for the 3.2 branch or would it go into master/4.0 too? See the conversation in #837 and #178 - the idea that each "Metric" has a set of "Attributes" (name/value) off it. I'm not sure on the status of those but maybe instead of a MetricType enum, allow filtering by String based "attribute names" and just provide a helper class with the list of standard/known attribute names that currently exist (what is present in the MetricType enum currently). For 3.2 the enum makes sense as there's a fixed number of attributes, for 4.0 if #837 becomes a thing then this would just want to be changed to a String (suppose there'd be so many other breaking changes that it could just be worried about at that point). Anyway, thought of it when I saw the comment about "metric types".
@ryanrupp Good point. This would only go to 3.2, for exactly the reasons you mention. Also there will be some inversion of control with regard to reporters in v4 to make this sort of filtering easier to implement.
@arteam Ryan reminded me that we're calling these 'Attributes', can we rename MetricType and disabledMetricTypes to MetricAttribute and disabledMetricAttributes?
Feb 15, 2017
This was referenced
Feb 17, 2017
Q1- Is the change at these lines similar to any other changes (from other locations of the same commit or from other commits)? (yes, no, not sure)
Q2- Can you briefly describe the change and why you made it? (for example, checking parameter before calling the method to avoid a Null Pointer Exception)
Q3- Can you give it a name? (for example, Null Check)
Q4- Would you like to have this change automated by a tool? (Yes, No, Already automated)
The data collected from the answers will never be associated with you or your project. Our questions are about recurring code changes from the developer community, not about personal information. All the data is merged across recurring changes from GitHub repositories. We will publish aggregated data from the trends of the whole community.