ReVanced
|
Hi. Sorry for bad english. Is there any plans to rename your microG fork to something else ? (For example ReVanced companion) Now there are two identical looking applications with the same name but with different purposes, this confuses users. People constantly come to discussions of the original microG on various platforms, and insist that they are right. Please consider changing the name and icon of your gmscore to clear up this confusion. Thanks. |
Replies: 7 comments 12 replies
|
The fork is meant to receive as little changes as possible to fulfill its needs. Refer to the following discussion/ explanation: ReVanced/GmsCore#9 (comment) |
|
Vavun is right - on upstream microG repo ReVanced users have been mistakenly reporting issues with fork supporting ReVanced for the last few days. A rename of the fork seems reasonable, and even necessary to avoid further confusion. |
|
That was caused by a problem with users browsers that opened a Google search instead of opening the correct link leading to upstream because it was the first search result. |
|
Most revanced users don't even know about the existence of upstream microG. Similar situations often happened even when revanced microG existed, now it happens on a regular basis. |
|
@oSumAtrIX Alternatively, revanced and other applications could rely on the user-install microG build in the future. Perhaps you will consider joining its development. |
Even in this PR, the microG creator prefers that the microG fork not call itself microG so as not to confuse users.
|
|
Yet users you have failed to properly educate keep reporting errors on the wrong repo, which you pretend doesn't matter, as if it's none of your business, when in fact it's partly caused by you. |
|
I have already replied once to you explaining why it did. #1035 (reply in thread) The last issue mentioning ReVanced was opened a week ago some of which are very much opened in the correct place and the amount of issues is only destined to reduce down to an inevitable amount as time passes. The fork won't be renamed as part of https://github.com/ReVanced/GmsCore?tab=readme-ov-file#about-this-fork and neither does upstream ask us to. |
|
@mar-v-in, could you please give your opinion on this situation? |
|
@oSumAtrIX which one is correct one for revanced ? one Details
Two Details
|
|
The one the patched app redirects users to install. |
|
I was wondering why you don't just integrate the parts of microG that you need into the ReVanced Manager app. This would safe users the hazzle to install an additional app, allows to directly integrate and configure microG from the Manager app, and generally means less confusion - because users don't need to know that microG is involved. The current situation is especially confusing for those that already use microG and want to use ReVanced, as they need to install two microG's which look exactly the same but have an entirely different purpose. MicroG is open source, which means I want you to use and remix the code as you see fit. However, this doesn't entail creating incompatible versions that look confusingly similar. Having the code open source also means you have the ability - compared to patching proprietary apps like ReVanced normally does - to easily completely resemble microG. Make use of this freedom for the benefit of both projects! |
|
Thanks. Naturally, some things are left unconsidered from a perspective such as yours. An example is that ReVanced Manager is agnostic to patches that ReVanced Manager can apply to apps. GmsCore is a dependency of a specific patch used to modify applications so they can use a specially prepared version of GmsCore. For that reason, the idea of integrating GmsCore into ReVanced Manager is impossible due to said ReVanced Manager's agnostic view of patches. Depicted by this example, there's many other missing considerations, which make it difficult to judge the current situation without deep insight into the situation. The fork we have focuses on as few changes as possible to fulfill its purpose as a dependency for said patch. Past forks by others who lost this trail eventually had to be discontinued due to the immense burden of merging upstream and keeping up with maintenance burden, which is something that we will avoid as much as possible, also mentioned in our forked version of the README: Goals of this fork:
Nongoals of this fork:
Renaming the application for the cases of users having the forked and non forked version installed, is a nongoal and as for such is a matter of the user to handle for themselves. For example (but not limited to), a launcher to change the name or icon (be creative). Our fork will differ as little as possible to upstream in order to exactly fulfill its purpose for which it was forked for and non-goals must be incorporated in different branches as an extension to the goals of the fork. Users have opened some issues for our fork on upstream for the reason that some browsers failed to handle an intent launched by a patched application to open the GitHub release page of our fork and instead just made a Google search. Google showed upstream as the first search result. We already worked around this issue caused by these particular browsers, and thus upstream was stopped being disturbed, eliminating further needs to incorporate nongoals to solve this particular issue. Please do not disturb microG anymore and have them go out of their way and involve them in discussions related to ReVanced when they have nothing to do with ReVanced. If there are issues in the future caused to microG by us in the future, respective maintainers should not hesitate to reach out to |
If running next to microG is a goal of the fork, it should not create the same icon in app drawer, for an app with the same UI, as otherwise, people will be confused. Saying that users can use another launcher that allows them to change the icon of both independently really doesn't do it, because even then, the icon and name in system settings, in app switcher, and so on, remain the same for both. The UX for people that already use microG really seems to be minor to you if you consider this acceptable.
Just the fact that the manager is agnostic to the patches it can apply doesn't mean that you couldn't include some code in ReVanced Manager that then can be used by apps after being patched. Making the patch rely on ReVanced Manager to be installed is just as "agnostic" as making the patch rely on a special patched custom GMS (based on microG) being installed. Alternatively you can also adjust the patch to include the relevant parts of microG in the patch, so that the patched app does not need a second app to work (e.g. account would technically be managed in the patched app itself). This wouldn't also improve UX for users, as they only need to install the patched app that would work easily and out of the box for every user.
I understand why this might become an issue for you, but also note that additional maintenance burden for upstream caused by user complains (that don't always make it obvious that they're in fact talking about ReVanced) is not a solution either. If your approach is to reduce your maintenance burden by increasing mine, I'm strongly advocating against such approach ;) Changing the app icon, app name, launcher icon and launcher name to e.g. "ReVanced microG" really is not a huge diff to maintain, but it already improves situation a lot. |
|
This discussion is ReVanced-specific, and I don't want to burden upstream maintainers with involvement in this discussion unless it somehow concerns them. Feel free to dip out of it.
The goal is to run next to an existing GMS installation. It does not specialize on a specific one, microG GmsCore is listed as an example, so there's no incentive to make such changes based on a specific case like microG GmsCore when the goal is generalized. Regarding the patch and ReVanced Manager, ReVanced Manager is not a suitable location to include GMS-specific or patch code. It is agnostic towards any patch, and changes to ReVanced Manager with the incentive to break this agnostic design towards any patch or specific purpose, such as GMS, can't be done by design. The base implementation of the patch used to modify apps to use custom GMS is agnostic to any specific app, and making it shade the entire code of a GMS would involve an immense amount of work and considerations, which is unviable. The patch modifies apps and changes strings or references to point to the custom GMS (next to other miscellaneous changes). Next to that, it will also ensure the user has a valid installation of the selected custom GMS, and by default, the user will be asked to download our forked version if it's missing. This approach works very cleanly and has minimal overhead for the user without burdening an immense amount of work on maintenance. Regarding users complaining upstream, I have mentioned in my previous comment that this was a temporal issue caused by browsers implementing the intent to launch the download link as described in my previous paragraph incorrectly and instead making a Google search leading to upstream, which we already solved, evidently from the fact that issues opened upstream have been reduced down to an inevitable amount (Next to ones we redirect users to in case seen fit). Unless that changes, no incentive exists to make additional changes to fight against this. Regarding changing the name and icon, we would need it to be part of the goal of the fork, which it isn't. The most but only appealing argument is that there may be two installations of GmsCore, but that is an occurrence that the fork can not handle because it is a specific problem and not a generalizable one (The fork is meant to run next to any GMS installation, agnostic to any specific one, microG GmsCoe is a specific one). Even for this specific case, I have named a good solution that affected users can apply. The fork is not supposed to actively or passively impersonate upstream or the microG organization, but I am conflicted with making changes to the fork, violating its goal. Forking is merely branching, and in terms of that, the existing changes neatly fulfil the purpose and goals of the fork. After all, this fork is just GmsCore, but with the ability to change the package name (https://github.com/ReVanced/GmsCore/blob/main/build.gradle#L8), which does not qualify to be labelled any differently. Maybe we can meet in the middle and create a branch with only the necessary changes supporting the goal, then merge it to our master branch and extend it with changes such as README, CI or, related to this case, upstream-specific stuff such as the icon or app name. Regarding that, we need to know what qualifies as such and adequately change them everywhere, such as references in the app (microG GmsCore is mentioned in the Google SafetyNet preference screen, for example) or the app name. Once again, this discussion is ReVanced-specific, and upstream maintainers are not supposed to be burdened with this question because this does not concern them, but they can feel free to. |
I asked this about two years ago |
|
That won't happen, refer to my comment #1035 (reply in thread) |
The fork is meant to receive as little changes as possible to fulfill its needs. Refer to the following discussion/ explanation: ReVanced/GmsCore#9 (comment)