Track DeprecatedFlyString
Closed this issue · 7 comments
There's over 1000 of them right now, and they're ignored by the tracking. It'd be nice to graph them alongside the DeprecatedStrings.
(I did attempt this briefly but I don't know gnuplot, or Python really. 😅 )
Hmm. In the ideal solution, all three stats (FIXMEs, Deprecated{Fly,}String) would be in the same graph, and you could easily scroll around in it. However, it's a problem of scale: 1000 DFlyStrings would barely register on the DString graph. So it would have to be a third graph, which gets a bit silly.
I could take care of the data extraction and updates, but I don't feel good about just adding yet another graph. Can you come up with an idea of how to combine this reasonably?
Using log scale doesn't really fix the problem, because then the day-to-day changes aren't visible anymore. Independent y-axes also feel like a cheat, and it works only a few times before becoming confusing.
My original attempt was just changing the grep from
["git", "-C", SERENITY_DIR, "grep", "-F", "DeprecatedString"],
to
["git", "-C", SERENITY_DIR, "grep", "-iE", "DeprecatedString|DeprecatedFlyString"],
which would count them together. Maybe that's not so bad?
That would leave a few edge cases, but that's not really the thing I'm worried about. I'm rather worried about presentation on the website: See above for my reasoning on that.
Derp, only now I really understand what you were saying: Only track a single number, which is the combined count; no splitting up needed.
Yes, I'll do that. And because that requires recomputing a bunch of the numbers, I'll do it slightly different, perhaps, if I find the time for it ^^
Hehe, no worries. Yeah the two classes are connected enough that one line is probably fine imo.
Done! https://benwiederhake.github.io/serenity-fixmes/
The reason it took a bit more effort was that "old" commit statistics had to be recomputed. While at it, I also took the executive decision to ignore binary files. This might affect old commits slightly, but I'm not really into burning ~10k CPU seconds single-core in order to fix these marginally-off numbers. The "jump" isn't even visible:
Great! 😀