Maintainer #5396
Replies: 1 comment
-
Posted at 2022-11-23 by @gfwilliams 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? Posted at 2022-11-23 by Hank 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... Posted at 2022-11-23 by Serj 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 Posted at 2022-11-23 by user140377 When I want to find out the developer for an app I just look at the git history. Posted at 2022-11-24 by @gfwilliams
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.
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. Posted at 2022-11-24 by Hank
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 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 :) Posted at 2022-11-24 by @thyttan 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. Posted at 2022-11-24 by Serj
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" :) Posted at 2022-11-26 by @halemmerich 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. I think there could be made an argument for saying @gfwilliams 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 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 Posted at 2022-11-28 by @gfwilliams
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 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 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Posted at 2022-11-23 by Hank
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.
Beta Was this translation helpful? Give feedback.
All reactions