[UX] Do not merge devices that are not straightforward to flash in Main (no official twrp,...)

[Gredin67]

It is the second time I try to use OpenAndroidInstaller and find no working TWRP although the device is said supported :

• Xiaomi Redmi 7A missing instructions for stock upgrade to android 10 #352
• flashing lancelot fails #432

As a user and a small contributor, I find it disturbing to mark a device as supported when the device cannot actually be flashed by openandroidinstaller (or at least not by a simple unexperienced user). The idea behind this tool is I can tell to someone by looking at the supported devices list that I can flash his device within less than 1 hour. But if I try OAI and realize later it is not working, then I lose even more time trying, and then manually flashing.

I would suggest not to merge in main branch devices that have not been tested by a contributor. That would save time to many normal users (and contributors like me). A branch "to-be-tested" could be maintained for contributors to test the devices and suggested TWRP.
A device would be merged in Main only if:

• A recovery was tested successfully
• If no official TWRP is provided, a link to a tested non-official one is provided

[ghost]

In the case of Xiami Redmi 7A (aka pine / Mi439), there is official TWRP support, and it's working. I don't know what you've done to miss it...
In the case of lancelot, you're right, there is an issue with TWRP. It may be corrected with #448.
Also, untested flag should warn users... It's also reminded before the installation process IIR.

[MagicLike]

I would suggest not to merge in main branch devices that have not been tested by a contributor. That would save time to many normal users (and contributors like me). A branch "to-be-tested" could be maintained for contributors to test the devices and suggested TWRP.
A device would be merged in Main only if:

• A recovery was tested successfully
• If no official TWRP is provided, a link to a tested non-official one is provided

I don't think this is a good idea. You are talking about new users to whom it should be straight forward what to do. If application side support would be hidden from them in some other branch, it would only make things more complicated. We as maintainers would also have to keep the branch up-to-date every time something changes, which increases workload.
To warn users from untested devices, there is a untested flag in place. The flag system could be expanded with for example one for a missing / non-official TWRP to give users an additional warning. What do you think?

[Gredin67]

The flag system could be expanded with for example one for a missing / non-official TWRP to give users an additional warning

To me this is the whole point. A device with no OAI-supported recovery available (TWRP and maybe soon OrangeFox) cannot be named "untested", it is just "not working". I mean in order to run OAI you need a supported OS AND recovery. Or maybe I am missing a use-case of OAI where the users have to install TWRP manually ?

[Gredin67]

In the case of Xiami Redmi 7A (aka pine / Mi439), there is official TWRP support, and it's working

At the time you released OAI-mi439 support, the corresponding TWRP had not been released. So it was bad timing for me at that time in this case because I tried in between.

[MagicLike]

The flag system could be expanded with for example one for a missing / non-official TWRP to give users an additional warning

To me this is the whole point. A device with no OAI-supported recovery available (TWRP and maybe soon OrangeFox) cannot be named "untested", it is just "not working". I mean in order to run OAI you need a supported OS AND recovery. Or maybe I am missing a use-case of OAI where the users have to install TWRP manually ?

Currently, the whole check of the files is very limited, but I haven't worked on it - tagging @tsterbak for this

[tsterbak]

Hi @Gredin67, thank you for raising this issue.

I think you are right and we should try to move a bit slower with merging support for new devices. On the other hand, this is a beta software and getting users to test their device is much easier if we add "support" for them with an untested flag and then gather their feedback. Doing the full python setup is a hurdle for occasional contributors who just want to test their device.

That said, I like the idea of a "to-be-tested" branch. We could start doing two releases, one including untested devices, only distributed on github releases. And the official release with only tested devices. Would that help solve this issue? Then I would move forward here. Also tagging @anon1892 and @MagicLike :)

[MagicLike]

Hi @Gredin67, thank you for raising this issue.

I think you are right and we should try to move a bit slower with merging support for new devices. On the other hand, this is a beta software and getting users to test their device is much easier if we add "support" for them with an untested flag and then gather their feedback. Doing the full python setup is a hurdle for occasional contributors who just want to test their device.

That said, I like the idea of a "to-be-tested" branch. We could start doing two releases, one including untested devices, only distributed on github releases. And the official release with only tested devices. Would that help solve this issue? Then I would move forward here. Also tagging @anon1892 and @MagicLike :)

I see a potential for complicated merge conflicts / messed up merges and files getting outdated, when two release branches are used. Maybe we should get back on the advanced mode pitch in #88 (comment) and #105 (comment) which can me used to test devices.