Abstract: Testing branch?

[Kreyren]

There are many scripts that are in testing and doesn't work as expected -> Recommends making a testing branch and move them in this branch.

Testing branch should be also disabled by default and triggerable from settings with warning.

Expected : Set strict standart for functionality of phoenicis. -> Only platinum scripts with support for LINUX are accepted by default for linux (same for MACOSX).

In theory scripts that are expected to work on platinum should be differenciated by a different color in apps? -> flag in script.json ?

[madoar]

There are many scripts that are in testing and doesn't work as expected -> Recommends making a testing branch and move them in this branch.

What benefit does the creation of a separate branch for testing scripts have? The issue with a testing branch is, that someone needs to manually move the scripts from the master branch to the testing branch and the other way. I wouldn't recommend this, because it is quite a lot of work.

Expected : Set strict standart for functionality of phoenicis. -> Only platinum scripts with support for LINUX are accepted by default for linux (same for MACOSX).

Again this would require a lot of manual maintenance. I've seen a few applications that went from platinum to bronze or garbage because of an update. If such a thing happens we would require users to detect this and adjust the scripts accordingly.

I think it is a good idea to mark the testing scripts somehow, maybe with a symbol in a corner of the associated application miniature. Again this can lead to problems if multiple scripts exist for an application (for example Local, Global and Demo), and only a subset of these scripts are marked with testing.

[Kreyren]

@madoar

What benefit does the creation of a separate branch for testing scripts have? The issue with a testing branch is, that someone needs to manually move the scripts from the master branch to the testing branch and the other way. I wouldn't recommend this, because it is quite a lot of work.

Afaik the main issue with compatibility layet managers is that they simply does not work alike lutris, playonlinux, etc..

Proton has strict rules to what can be added to whitelist and i think that we should implement it to to prevent unexpected result for the end-user when he/she opens a script in phoenicis and it outputs error.

Benefits of this are that we will for sure know that scripts that conform the stated checklist are 100% working on platinum.

Or do we really want to provide non-working scripts to the end-user?

Again this would require a lot of manual maintenance. I've seen a few applications that went from platinum to bronze or garbage because of an update. If such a thing happens we would require users to detect this and adjust the scripts accordingly.

That's what is expected if there is a problem with a game end-user/tester creates a github issue and we can push it to testing untill it's fixed.. It does require more work, but i believe that it's mandatory otherwise we would have POL 4/lutris with most scripts not working -> unusable software for the end-user

also about the updates we can make a script that are specified on each version and wait for someone to confirm that they are working to be pushed in non-testing.

[ImperatorS79]

Yes but you can only install those apps by checking the testing check-box. So no problems for the end-user. Maybe revive #361 ?

[plata]

We can think about marking a script as "testing" in the apps tab more clearly. If anyone would like to have this, please open a new issue.

This one is "won't fix" for all the reasons mentioned above.

[Kreyren]

@ImperatorS79 I think that same could be achieved by adding comments? Aldo it would be goodto warn the end-user about the issues alike DXVK regression on AMDGPU etc..

@plata i would still recommend some checklist to push script into an official release. Based on my experience it's mandatory -> If script doesn't work as expected it shoudn't be part of official release.

[plata]

That would mean that we have to test all scripts before a release. This is simply impossible.

[Kreyren]

@plata Well i see what you mean.. If there is a problem with manpower to test all the scripts i would make something like verification that the script worked on this version etc.. so that it can be verified by a community.

Or in theory we can have something built-in that would make a rating for each script based on end-user feedback and comments.

i'm saying that current design is not sufficient for the usage there might be a lot of ways to include it.

[plata]

We simply have to face the reality that we cannot assure (also not with community support) that all scripts are working. You even have regression in plain Wine. The best we can do is fix the script if an issue is reported.

[Kreyren]

Still i think that we can solve this using UI alike check if checksum matches if not warn the user about possible compatibility issues and to output debug message to be filed in github issue if the game is not working (alike on POL4)

[madoar]

@Kreyren what do you mean by check if checksum matches? I agree in case a script is not working as intended we should add a button to Phoenicis (maybe the application details window or the container tab?) which allows the user to report a bug.

[plata]

What you suggest is basically a "Report issue" button, right? I think we can do that. You can open an issue for this in the software repository.

[Kreyren]

Something alike.. expected result is to have some kind of control over what scripts are working -> that we can guarantee that script A is working

[madoar]

@Kreyren the issue is, that we simply can't know with 100% certainty which scripts are working and which not. In most cases we don't own the game/software and therefore can't test a script ourselves. In these cases we need to believe the authors of the scripts, otherwise we wouldn't be able to merge scripts for applications we don't own.

Additionally event sources like winehq can be outdated. Quite a lot of test reports on winehq are several months old. Who can say whether the tested software has been updated and still works with wine?

[madoar]

@plata see https://github.com/PhoenicisOrg/phoenicis/issues/1776

[Kreyren]

Well in theory we can have some kind of GUI that expects user feedback alike this version works on this GPU using this DXVK confirmed by this USER for this checksum/version of a file. Then we can practically have something like wineHQ with rating for each version and method to install that version assuming that launcher won't auto-update it.

^^^ practically how lutris have it implemented, but instead of rating by moderator we would have a rating from (trusted) userinput.

(trying to build concept)

Practically any quality assurance system is helpful.

[madoar]

I agree such a system is useful, but it has a simple problem in our case: such a system requires a lot of users to provide trustworthy ratings. Phoenicis currently doesn't have a lot of users. This means that most applications won't have any evaluation at all, or a few possibly outdated ones.

I think we should move the discussion, about adding an evaluation system for scripts to Phoenicis, for when we have more users who are interesting in helping maintaining the scripts.

[Kreyren]

@madoar We can display the rating if more then X users contributed and allow end-users to report spam ratings.

• we can have verified users which rating would be pushed automatically who knows how to test the script etc..

I would implement some proof of concept now and work on it if there is a time.. it would attract more users.

[madoar]

If we add such a system too early, i.e. when not many users are using Phoenicis, the rating system can be perceived as not accepted by the users. This in turn would lead to nobody using the system when Phoenicis has more users.

Therefore I would move the decision to add such a system to when we have enough users for it. Nothing is worse for a software than having functionality that is useless because it doesn't provide any benefits to the user.

[Kreyren]

Disagree we are in alpha we should work on concept and design. Something that just proves the concept bare bone should be implemented now and if the concept is functional and usefull in practice we should finish it in beta -> once everything in beta is finished -> GOLD.