Top 10 of bindings having the most of open issues #13706
Comments
lolodomo
changed the title
|
Maybe maintainers of the bindings could look at the issues to see if they are all still relevant ?
|
|
Other bindings which are below the top 10 but with a certain number of issues: |
|
re Shelly: |
|
regarding homekit - I could close some old and obsolete tickets, waiting for feedback for one more. remaining 6 are valid feature requests and bugs. |
|
what about feature requests that are valid but not implemented yet? I do not think is useful to close them, as they may get addressed in the future |
Yes but at the same time, if a feature request is there since several years and generate no developer interest, we could consider it is time to close it? Maybe after two years for example? |
|
honestly I see this as just a loss of information. |
|
Regarding JS Scripting: I am working on #12577, I’ll also have a look at the other open issues. |
Ok, I think we can keep them. Anyway, I am not deciding. |
|
Thank you for your efforts, I will update the top during the weekend. |
|
Maybe @ZzetT could have a look for the telegram binding, @kaikreuzer for the chromecast binding, @lujop for the influxdb binding |
|
@lolodomo Great to see your effort here. Perhaps this would be worth an AC discussion. |
Why such anarchy / nightmare for the final user was introduced ? :(
A solution has to be found, that is clear ! What are the bindings concerned ?
Probably. This is limited to only few members ? I am not sure I have an access... What disappointment for me to read that ! |
This is not true. The rules have ben adjusted to this version AFTER the marketplace was introduced. Anyway, even without the marketplace (or any other add-on service): you can't force people to develop within the openHAB organization. There always have been add-ons not included in the distribution and there always have been modified versions of add-ons. |
I am wondering why one doesn't want to develop within the openHAB organization. If there is a reason/problem, we maybe can discuss and solve it, because having forks of official add-ons is type of confusing for the end users. |
|
Hi @lolodomo |
I am sure the following discussion will irritate me and disappoint me. |
While I'm normally as annoyed by not focusing on the topic at hand, I think it could be relevant. Though I do want to focus my comments on resolving issues, and hopefully without offending any involved party, since that's not my intent. Anyhow, I think that having this discussion is on topic, since resolving it will allow cleaning up large chunks of issues, which is the core ask for THIS original topic. I don't know the full history here, since I haven't been involved with openHAB for as long as others. But I have worked with and committed to all three repositories (openhab-core, openhab-addons, and smarthomej/addons) within the last few months. I'd agree with @lolodomo that it can be confusing and frustrating to an end user when an official plugin has issues, and then you find out there's a different version that's more well maintained. On the flip side, I also agree with @J-N-K that it's impossible to prevent someone from maintaining an alternate version of a binding outside of this repository -- being able to easily fork, improve, and share your improvements in whatever manner is what makes open source great. So how do you reconcile those two things? It seems there are a few choices:
Putting myself in the shoes of an end user unfamiliar with the situation, option 3 would obviously be best. Option 4 also wouldn't be so bad - and would add even more weight to OpenHAB officially endorsing "there are community addons that we don't officially maintain or endorse individually, but do endorse other community member's freedom to maintain and distribute addons that may not be fit to be in the main distribution." Option 1 definitely seems like the worst of the 4. So... please! Can we at least move away from option 1?! |
|
I agree that the status quo is not great. The confusion we put on the end users by having multiple forks of some addons, and, as ccutrer stated out, the risk that users are
shouldn‘t be accepted here. I am aware that there is some history that lead to forked addons, and I personally welcome that there are addons developed somewhere else, as this is open source, but I‘d be happy if come to a decision here (or in another thread). Coming to the choices that ccutrer listed:
|
|
@wborn @kaikreuzer : do you know how to move all the messages about openHAB vs smarthomej elsewhere (separate issue?) to continue that interesting discussion not in this issue ? |
|
I'm sorry, I've been not able to dedicate time to the addon, and in the short term, I don't expect that to change. |
I don't think there is any built-in functionality for that in GitHub. The closest thing would probably be to split it off manually by creating a separate issue and then copy/paste/quote all comments from this issue to that issue and delete them here. E.g. by imitating the bot in openhab/openhab-core#2276. |
|
Thanks for taking the time to compile the list and also all that you do here @lolodomo Wanted to raise that some of the people marked as the code owner / maintainer may no longer be part of this project (unless this has been looked at recently), I suspect this is the case with telegram and also mqtt which feature in your top 10 list. Perhaps getting new people that make decent PR in recent times as the new codeowner may help reduce the workload. |
|
Thanks @lolodomo for this list. Just created a new issue to proceed that discussion about the bindings developed elsewhere. So hopefully we can get back to this topic. :-) Do you have a simple tool to generate these statistics? Maybe worth spending a bit of time on the github api to automate a monthly report or per milestone release update of this top 10 list? |
No, it is done and updated manually. |
|
@lolodomo I do really appreciate your initiative with highlighting erroneous add-ons. However it looks like not much happened regarding closing those. What it normally takes to fix #13692 like in my case deconz add-on. I must stay with OH 3.2 as none of my zigbee sensors (all my sensors are zigbee) get registered. best regards |
Maintainers already helped to reduce the number of issues/RFC for certain bindings, thank you to them. |
Because there are 550+ issues and new ones appear while old ones get closed, it might not be very visible. But yeah many issues have been resolved, closed or validated. I'm still chasing the older issues and it seems many of htem have been fixed. |
|
@lolodomo your statement that Hue has 10 open issues is actually a bit unfair; a couple of the issues refer to the Hue Emulation binding, and one refers to the Deconz binding. But nevertheless many thanks for the issue tracking. |
No, I really counted only hue. We have now 11 for hue. |
I am not new to OpenHAB although not engaged as a code maintainer. I am missing to see how spread of add-on install bundles helps to end users. I had to downgrade to OH 3.2 since "standard" deconz addon suddenly got broken. Recently learned the hard way that there is smarthome/j where solution may be. It still remains for me to find whether smarthome/j is really providing deconz add-on compatible with OH 3.4. What is smarthome/j? Another home automation platform? |
This topic has moved to #14129. See also #14124 which is specific to your case. |
|
Created a very basic script that can help automate the list creation. It is based on the Github API. Just insert your personal API KEY and it logs the issue count per binding. Let me know if you think it can be of any help and/or if we can improve it. I hope this can add some value to reducing the issue count / bugs / enhancements. |
|
TOP 40: [DELETE THE LIST AS IT WAS FAULTY] |
|
@lsiepel nice job. |
Yes, the result of the script holds data from issues "mentioning" bindings apparently. I observed the same with Netatmo. |
|
Ah, it also includes pull requests. I have updated the script to filter those out of the query. And altered it a bit so it generated markup that can be copy/paste here immediate with url to details. List of all addons with 5 or more issues:
|
And it includes issues where there is a pull request already available to solve the issue, but nobody is willing to review the pull request, and thus solve the issue specifically, (and probably solve other issues too) |
Don’t think it is a matter of not willing to review. It’s rather a lack of time. But that’s somewhat off topic. The list consists of open issues and is meant to engage and solve issues. Let me know if there are issues or improvements needed to the supplied snippet. |
|
^ |
|
Here are all the commits since one year (https://github.com/openhab/openhab-addons/graphs/commit-activity) 37 Pull requests merged the last week. https://github.com/openhab/openhab-addons/pulse Of course more reviewers would be welcome and appreciated. |
|
I updated / fixed most of the open issues, they will be closed with the next PR merge. |
|
@lolodomo Can you update the list? |
|
State as of 21-05-2023: |
|
Any chance that the MQTT issues can be sorted further? Separate into |
|
Guessing this was accidentally unpinned? Have done it myself when scrolling on a mobile's tiny screen. |
|
@lolodomo The http binding has only 4 issues, the other issues are related to other bindings. Maybe you need to grep for |
|
shelly 29 Used the shared playcode snippet from before to generate this |
Here is the top of binding having at least 8 open issues / requests for change (2023 July 23):
These 11 bindings are the source of 26% of the currently open issues.
Maintainers of these bindings or new volunteers are encouraged to check these issues, propose fixes and close some of them if they are no more valid.
The text was updated successfully, but these errors were encountered: