Bindings maintained at multiple places

[lsiepel]

The last couple of weeks i have been chasing several older issues and i was noticed by @jlaur about some bindings maintaned elsewhere. He pointed me at #13706 where some of that came to light. The discussion that followed is very interesting and as far as i know it did not come to a conclusion yet.
I completely agree that that discussion was (partly) off-topic from the issue that @lolodomo raised and it would be better to have a seperate issue for it.

That is why i create this issue. I like to know how to proceed with bindings that are maintained at different places. If i understand it right, @hmerk raised an issue about this with the AC. I could not find it, but did it came to a conclusion?

@ccutrer pointed out there are about four options (feel free to add more suggestions):

1. The status quo. You don't. The official addons bitrot, and continue to ignore that smarthomej versions exist.
2. The official addons continue to bitrot, but at least add a note in their READMEs that acknowledge the existence of and links to smarthomej. Not a great experience, but at least makes it more possible for an end user to discover smarthomej, instead of getting frustrated at brokenness and apparent non-maintenance of an addon that might be critical to them, and losing them from the openHAB platform altogether.
3. Smarthomej (or at least those addons that duplicate official addons, but maybe all of them) merges back into the official repo. 4. Sounds like there's history here that may make this difficult.
4. openhab-addons admits that their version of these bindings have been abandoned, and that better versions are available in the community. Just remove them completely, possibly at least leaving their readmes in place on the openHAB docs website pointing to smarthomej.

Also @florian-h05 and others commented. So can we proceed with this discussion? Also to determine the size of this issue it might also be good to have a list of affected bindinds. My knowledge is limited :-) so please feel free to add bindings to this list:

• deCONZ Backport thread / all open issues

[florian-h05]

• KNX (no backport thread) / all open issues / smarthome/J version

Regarding KNX: I have talked to Jan a while ago, and if one wants to backport his improvements and fixes he is fine with that, we just need to make clear where we have the code from (copyright notice).
I have a gist that summarizes what is missing at openHAB: https://gist.github.com/florian-h05/e557413241b7050fd186cdaba52b3f9e.

In general, you can have a look at the SmartHome/J Addons Repo: https://github.com/smarthomej/addons/tree/3.2.x/bundles, since there are more

[FordPrfkt]

Until now i was unaware of the existence of smarthome/j and at the moment i fail to understand the benefits their versions over the official ones or the motivation behind forking the official addons. The Readme in their repo does not enlight me about that either. Maybe it would help if the maintainer of smarthome/j would give some explanation?

[J-N-K]

Difference and benefits can be derived from the Changelog. The motivation: ostly technical issues that can't be solved in openHAB at the moment. @kaikreuzer and me are working on resolving these.

[holgerfriedrich]

@J-N-K I could help porting back fixes into the KNX binding. I am not sure how to give credits, a joint signoff or just via the commit message as you recently did it for other backports?

[J-N-K]

@holgerfriedrich I'm currently only back porting changes in add-ons that do not require core-changes (i.e. those that do not depend on org.smarthomej.commons) because what is implemented there is the solution to the technical issues mentioned above. Once these functionality is implemented, I'm happy if you take over for KNX and a joint sign-off is fine.

[jlaur]

Short update - @J-N-K seems to be on fire at the moment. 😉

• influxdb: [influxdb] Code improvements and enhancements #14304 -> [influxdb] Remove add-on smarthomej/addons#459
• dmx: [dmx] Refactor and improve code #14327 -> [dmx] remove binding smarthomej/addons#455
• snmp: [snmp] Upgrades and enhancements #14330 -> [snmp] remove binding smarthomej/addons#456
• onewire: [onewire] Code improvements and bug fixes #14400 -> [onewire] remove binding smarthomej/addons#460
• tr064: [tr064] Enhancements, code improvements and fixes #14468 -> [tr064] remove binding smarthomej/addons#467
• knx: Can be tracked from [knx] Backport SmartHome/J enhancements and fixes #14502

And openhab/openhab-core#3330 has been reviewed by @kaikreuzer and just moments ago approved. I'm now crossing my fingers for a deconz backport. 🙂

[lsiepel]

Great! Already chasing some issues that could be closed.
For influxdb, i see some older issues and find it somewhat hard to determine if the issue is close4d or not. Off course i can ask all to check, but maybe @J-N-K can have a brief look at https://github.com/openhab/openhab-addons/issues?q=is%3Aissue+is%3Aopen+influxdb+in%3Atitle and comment on issues that might be fixed with the snmp backport.

Edit: oops completely hit the keyboard at the wrong place, here. Guess it is from excitement ;-)

[lsiepel]

Update: tr064 #14468 fixing 2 issues from this repo and adding a ton of other fixes.

[lsiepel]

I think allmost all bindings have been backported now, so i close this issue.

[lsiepel]

@J-N-K there are some bindings left that are both in smarthomej and in openhab repo's. Are there any plan's to also move them here?

Like amazoneechocontrol. It has some issues here, but i see most fixes where done by you in smarthomejj repo: https://github.com/smarthomej/addons/pulls?q=is%3Apr+amazonechocontrol+is%3Aclosed

[J-N-K]

I just added a backport for http. As far as I can see amazonechocontrol and androiddebugbridge are left. I can't do anything for the latter one, I don't use it and can't assess what needs to be done, because I believe some issues have been fixed/features added in both versions in different ways.

[lsiepel]

Close this now as most of the bindings (2 exceptions) are backported.