Template talk:Testing: Difference between revisions

From Dolphin Emulator Wiki
Jump to navigation Jump to search
Line 42: Line 42:


OK, I'm seeing a few issues in the wider deployment:
OK, I'm seeing a few issues in the wider deployment:
*Ishiiruka builds are not handled correctly resulting in in page error messages
*Ishiiruka builds are not handled correctly resulting in in page error messages (i.e. [[Just Dance 2015]]).
*Unless we initialize the test llastrevision 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. Very odd, may need further investigation.
*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)
[[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 00:57, 23 November 2015 (CET)

Revision as of 04:30, 23 November 2015

Handling of "User" Entry

The "User" entry needs a correction. The "Special:Contributions" page won't exist for users that aren't registered, and it's only displayed for such. I would lean to using the "Special:Contributions" page for users that exist and a generic search on the user name otherwise.Kolano 09:02, 17 February 2012 (CET)

Actually, on closer look, the "Special:Contributions" does work for registered users that don't have user pages. Not clear if there is a way to identify unregistered users and provide a generic search for them instead.Kolano 09:04, 17 February 2012 (CET)

Android Testing Results

I recently saw some users posting test results of Dolphin for Android in the forums. Should we start including them in the wiki? Jhonn (talk)

We can, I may need to make some template edits to handle categories, documentation updates, and etc for such. Kolano (talk) 08:28, 1 May 2014 (CEST)

The main problem I see is that... will users even know what's in their phones? Sure they will possibly know what their phone is, so I guess that gives us something to work from, but are you ok with getting CPU and GPU information from a phone name? And how to phone names fit in the template? - MaJoR (talk) 16:30, 5 May 2014 (CEST)

Well, if the user want to upload an Android test then we should require they at least know what CPU and GPU their phone have. Another possible (but a little ugly) solution would be matching CPU and GPU from a table (maybe in a sub template) with phone names to do the thing, so, in the test entry the user would just put something like this:

{{testing/entry|revision=4.0-xxx|OS=Android 4.3|phone=LG G2|result=Black screen, buggy drivers|tester=AndroidUser}}

and in the page it would be replaced by the common template (Revision=4.0-xxx, OS=Android 4.3, CPU=Krait 400 Quad Core @ 2.26GHz, GPU=Adreno 330). The main issue with this approach would be the big nightmares we would get, like maintaining the list updated with all of Android phones available, not to mention having a lot of entries for the same phone in the sub template table (Samsung Galaxies for example, flagship models get at least a Qualcomm variant and an Exynos variant in most cases) Jhonn (talk)


(quoting from Linux Purge discussion)

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. 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)... - 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). Kolano (talk) 22:17, 20 November 2015 (CET)

OK, now have this in place in the sandbox. Please let me know your thoughts. 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 {{VersionRevision|{{{revision|}}}}} is bigger or equal than {{#var:tl_testing_entry_lastrev|0}} (will automatically return 0 if it's the first entry).
  • If true, set tl_testing_entry_lastrev to {{VersionRevision|{{{revision|}}}}}
  • 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 {{s}}).
The whole logic can be done in a single {{#ifexpr}} that way! But independent of that, it looks really good to me, +1 for merging it in the main template! - 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 ({{#var:tl_testing_entry_lastrev|0}} 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). - Jhonn (talk) 05:56, 22 November 2015 (CET)
OK, will try to revise later today. Kolano (talk) 17:10, 22 November 2015 (CET)
Implemented, will take a while to parse through all the pages though. 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. Kolano (talk) 19:21, 21 November 2015 (CET)

I was thinking of reducing possible overhead (a somewhat working example is on {{s}}). However, I never researched if it really reduces the overhead or not. In that case we can just scrap the checks (in {{s}} too)... - 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.

Kolano (talk) 00:57, 23 November 2015 (CET)