|
|
| Line 20: |
Line 20: |
| It looks like you did capture some of the mobile CPU/GPU stuff. This also seems fine, though I also have a bad feeling many folks will have no idea what CPU/GPU are in their phones and we'll be cleaning stuff up a lot. I guess that would be dependent on actually getting some Android test results though. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 15:24, 17 November 2015 (CET) | | It looks like you did capture some of the mobile CPU/GPU stuff. This also seems fine, though I also have a bad feeling many folks will have no idea what CPU/GPU are in their phones and we'll be cleaning stuff up a lot. I guess that would be dependent on actually getting some Android test results though. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 15:24, 17 November 2015 (CET) |
| : I won't work on this for a while, just realized some other issues we'll certainly have in current design (e.g. two different devices may use exactly the same CPU/GPU and Android version and yet may perform completely different because of OEM shipping older/newer GPU drivers or one including optimizations not available in the other). Including device model would fix that but it would also probably require some redesigns. In other words, at least currently it's not worth the work needed, we still don't have any Android testing entry (on the wiki)... - [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]]) | | : I won't work on this for a while, just realized some other issues we'll certainly have in current design (e.g. two different devices may use exactly the same CPU/GPU and Android version and yet may perform completely different because of OEM shipping older/newer GPU drivers or one including optimizations not available in the other). Including device model would fix that but it would also probably require some redesigns. In other words, at least currently it's not worth the work needed, we still don't have any Android testing entry (on the wiki)... - [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]]) |
|
| |
| == Using Variables ==
| |
| So I've been contemplating how variables might be used to communicate among templates and get this template to do some more work for us. A couple things to try out...
| |
| *Setting a "Last Test Release" variable, and using it to flag when test results are out of release order (things like the 5.0-rc releases may muck with such a bit though, since there's a small overlapping range of point in time ids there).
| |
| *Use the "Last Test Release" variable in [[Template:Testing/end]] to generate categories indicating an age since the last test was performed (i.e. "Tested within 100 revisions", "Tested within 1000 revisions", etc). [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 22:17, 20 November 2015 (CET)
| |
|
| |
| OK, now have this in place [[Template:Testing/entry/sandbox/testcases|in the sandbox]]. Please let me know your thoughts. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 02:02, 21 November 2015 (CET)
| |
|
| |
| : The concept is very clever, I really like it, but I feel the current implementation, while working as intended, could be a little simpler:
| |
| :* Check if <nowiki>{{VersionRevision|{{{revision|}}}}}</nowiki> is bigger or equal than <nowiki>{{#var:tl_testing_entry_lastrev|0}}</nowiki> (will automatically return 0 if it's the first entry).
| |
| ::*If true, set tl_testing_entry_lastrev to <nowiki>{{VersionRevision|{{{revision|}}}}}</nowiki>
| |
| ::*If false, tag the page with the unordered category (and possibly set a flag to avoid reincluding the category again if already included, similar to {{tl|s}}).
| |
| : The whole logic can be done in a single <nowiki>{{#ifexpr}}</nowiki> that way! But independent of that, it looks really good to me, +1 for merging it in the main template! - [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]])
| |
|
| |
| The problem I had with that is that the #expr logic doesn't treat blank string as 0 and errors on ("" - #). So the variable needs to be initialized to 0 for things to work out or some conversion of "" to 0 performed. The pre-init in testing\start seemed like the least work, and also helps avoid things being non-initialized if a page includes no test entries.
| |
| : That's what the additional parameter in #var does (<nowiki>{{#var:tl_testing_entry_lastrev|0}}</nowiki> would return 0 if the variable is not set or empty, or whatever else you put in the parameter -- another example is in OS category, we save the regexp value in a variable, if no suitable string is found, the variable will be empty but will return "Linux" instead, because of the additional parameter). - [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]]) 05:56, 22 November 2015 (CET)
| |
| :: OK, will try to revise later today. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 17:10, 22 November 2015 (CET)
| |
| ::: Implemented, will take a while to parse through all the pages though. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 18:06, 22 November 2015 (CET)
| |
| Is there a good reason to worry about a category being included on a page multiple times? Such is invisible and it seems like more work to check before including each. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 19:21, 21 November 2015 (CET)
| |
| : I was thinking of reducing possible overhead (a somewhat working example is on {{tl|s}}). However, I never researched if it really reduces the overhead or not. In that case we can just scrap the checks (in {{tl|s}} too)... - [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]]) 05:56, 22 November 2015 (CET)
| |
|
| |
| OK, I'm seeing a few issues in the wider deployment:
| |
| *Ishiiruka builds are not handled correctly resulting in in page error messages (i.e. [[Just Dance 2015]]).
| |
| *Unless we initialize the test lastrevision var to 0 in testing\start something in the infobox seems to cause the lastrevision variable to be set to the value for 4.0-4.0.2 on pages with parenthesis in their name. That's very odd and may need further investigation.
| |
| [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 00:57, 23 November 2015 (CET)
| |