You are reading a single comment by @halemmerich and its replies. Click here to read the full conversation.
  • There is already a link to the apps folder on github and one click further (History) gets you all commits for that app. Usually it is possible to make out creator and main contributors for an app at a glance that way.
    Automatically detecting that by amount of changes etc. is difficult. Someone reformatting the code for example would appear to having rewritten the complete app as close to every line would have changes. Another problem would be apploader forks.

    I think there could be made an argument for saying @Gordon is the maintainer of the espruino/BangleApps repository and practically for all apps there, since he merges the pull requests and has an eye on the changes. Similarly everybody forking that repo and publishing a custom apploader essentially becomes maintainer for all apps on that fork. A fork not keeping the apps current becomes a fork with changes against the espruino repo by default after some time.

    Manually tracking one person as a maintainer in the metadata would mean this person being shown as maintainer in each an every of the currently over 800 forks.

    Maybe the problem of forked apps could be a bit alleviated by defining those as variant of the same thing and show only that in the apploader. For example the whole crop of bluetooth widgets (widbt, widbthide, widbt_notify, widminbt) could all be marked as widbt variants and the apploader could show only that one variant as app and ask the user which one to actually install in a second step. That would essentially be the same as is done with the provides tag in metadata for modules.
    I initially implemented gpstrek as a duplicate of gpsnav. While it never got on the official apploader in the initial stages, it would have been a prime candidate for this variant mechanic. It could have lived as a variant and then after some development it got different enough for not being a variant anymore (the route feature, completely new gui, background running). I had decided to not make a pull request as long it was to similar to the original, but essentially it already had some improvements that could have been useful in the apploader as a variant.

    A second step could be deprecating apps that way and not show them any longer in the apploader by default. Forks could be created for a specific and if they are functionally fully supersede the original app at some point, both could be marked as deprecated and deprecatedBy to filter those out during display as well. A new widclosebutton with settings for what to load could deprecate widclose and widcloselaunch this way while keeping those available for people still using them. There could also be hints in the apploader to change from widclose to widclosebutton. Something like this could be a way to implement a grace period before actually removing apps from the official apploader.

About

Avatar for halemmerich @halemmerich started