Maintainer

Posted on
  • Would it make sense to add a maintainer property to the metadata.json?
    That could be a foum user name or a clear name of the app/watchface main maintainer(s) or a value like "not set", "anonymous", "free to take over". If it's a user name, we could even link from the app loader to the forum.

  • We could do? So the idea is if you have issues or suggestions you contact the author?

    So maybe it makes sense for it to be a URL? Either twitter, forum, or maybe email?

  • My intention was more the developer to developer perspective. Say, when I want to add a feature to an app, I maybe would like to ask the maintainer if adding it would fit in his global concept of the app. Otherwise I would just add a fork of the app and take control. That might also reduce the amount of forks. Many forks may confuse the user. E.g. we have multiple BT status widgets and in future multiple message apps maybe...

  • In general, it would be nice to have a separate section in the App store with 'Patches'. Where would be a small additions to existing applications or duplicate applications with some changes.

    It's would be like that: BT status widgets - patch 0.1
    or that: BT status widgets - color patch
    next: BT status widgets - awesome patch

  • When I want to find out the developer for an app I just look at the git history.

  • When I want to find out the developer for an app I just look at the git history.

    Yes, exactly, it's usually quite easy. I guess maybe it would be possible to use the Github API to dig out who the authors were in an easy way? Or maybe there's a page I could just link to as I know GitHub lists icons for the top authors at the top of the directory list usually.

    it would be nice to have a separate section in the App store with 'Patches'

    In theory I like this - I've been trying to tweak some of the apps in the app store (eg to allow fast loading, or swipeable widgets) and it's amazingly frustrating to find a whole bunch of apps that are basically identical apart from 2 lines of code.

    But I just wonder whether anyone would actually use this? Handling patches is quite advanced when many contributors haven't even used Git before. Also patches themselves would need maintaining if an app changed as they may then not apply cleanly. Not to mention how painful they would be to debug or change.

  • Yes, exactly, it's usually quite easy. I guess maybe it would be possible to use the Github API to dig out who the authors were in an easy way? Or maybe there's a page I could just link to as I know GitHub lists icons for the top authors at the top of the directory list usually.

    I know that GIT has this feature. But to see it in the app loader would be just much more convenient. And if I do a quick patch I don't want to appear as the maintainer.
    I'd be ok with an optional field in the json. That way a maintainer also can intentionally set an app as "free to take over" for any other user because he doesn't want to maintain it anymore.
    The patch approach is very interesting, but I also doubt the user would understand.

    I just want to encourage developers to get in contact with each other before they just make a new fork to implement a small feature that could have been an option in the settings :)
    Making a fork is very easy - implementing a feature to other developers apps is more a communication thing some people might just want to skip.

  • Maybe a suggestion/instruction somwhere (the wiki/one of the guides?) about ideal ways to imlement small/big changes to existing apps regarding collaborating on the one app vs. forking. I think it's easy to @tag previous contributors either with a question or just as fyi kind of thing.

    Not saying the maintainer idea is a bad one - but it's one more thing to keep track of.

  • Also patches themselves would need maintaining if an app changed as they may then not apply cleanly. Not to mention how painful they would be to debug or change.

    There's more to think about, but the simplest solution is to explicitly include the word "Patch" in the JSON of the application if it's a fork with minimal edits.

    There will be an agreement: if your new application is an almost complete clone with minimal edits, then you must definitely specify the word "Patch" in the JSON. Further, such forked new applications will be placed in the "Patches" tab, where there can be any number of identical applications with minimal edits. How about this?

    Ideally, there will be automation: a new app is being checked for a code match, if the code base matches by 80% (suppose), then the new app is automatically assigned the word "Patch" in its JSON, also can add a small ID in the form of a hash to the name. And all this is automatic.

    Further, the author of the main origin app could use such patches for their origin app or ignore thats "patches" :)

  • 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.

  • defining those as variant of the same thing

    Yes, this could be an option (especially for existing apps). Personally I'd really like to discourage forks with minor changes though - it's better for everyone (IMO) if a feature can be added to the original app, rather than having 5 apps each with extra features, but not one app that has them all. Not to mention what a nightmare maintenance is.

    While we could add an option to mark deprecated someone has to actually do that, and realistically that's going to mean that it'll end up being my job to try and 'clear up' after everyone else, and then get shouted at by the one person that still uses said deprecated app.

    There are definitely cases (eg minimal clocks like Anton Clock) where just expanding the app turned out to be a bad idea, but it seems like having at most two apps - the basic one, and a ++ version, is probably better for the majority of users.

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

Maintainer

Posted by Avatar for Hank @Hank

Actions