Test modbus before it is released.

[janiversen]

@crug80 @joostlek
I have changed this custom component to contain the not released Pull Requests and my queue of not submitted pull requests. The queue exist, because sometimes it takes quite a while to get simple Pull Requests approved (like the 2 I have open right now) and after that it takes up to a month to be included in a release.

Since I would like to speed up getting the modbus integration into a better shape, I find this "shortcut" worth my time, and something really helpful for users who are then enabled to do early testing.

The custom component is based on the newest dev, but regulated so it works with the latest release (e.g. no bump of Pymodbus), and PLEASE remember the intention is NOT to have a modbus custom component, but only a queue of not YET merged/released Pull requests.

This custom component allows myself, but more importantly users who have a problem, to test if their problems are solved, without having to wait months, which again can give us early feedback and thus ensure the next release is more stable.

I am aware that we are not allowed to promote custom components on the homeassistant issue tracker, but I think it would be helpful to add a pointer in issues solved (if not it can always be done in the user forum, and then with a link to that instead).

Would like to hear your opions.

[joostlek]

2 things:

1. Once you get someone to install a custom component, they're happy and they forget that they have a custom component installed. So generally I am hesitant to explain to people how to do it, unless there's low risk. If it's an integration I am actively developing I am certainly not doing that. Modbus has quite the number of users, I think it will bite us, because not only current people will try this, future people will as well because they google, with the biggest downside being that they can mess up their system. So I would be slightly against using this as an early access for the majority of users.
2. The license of the custom component is invalid. Because the base of this code is from the Home Assistant core repository, which is licensed under apache-2.0, which you now relicensed under a modified license, you would need to ask permission to all the users who once committed to the project to change the license.

[janiversen]

1. that is a risk.
2. No that is not correct, the changes in that repo is correctly based on code with Apache 2 license, but the commits in the repo could even be sold, apache 2 permits that, I should know being an apache member, and please remember the strict license is to avoid, that it is used to create other versions of the modbus component.

[janiversen]

In respect of 1. yes it is a risk, but it also a risk that users with a problem google to solve the problem and end up with the same solution.

I need to maintain this, if not for nothing else, then for my production environment, I am NOT prepared to wait months if I have a problem in production, and right now I have quite a number....due to changing back to the official component.

[joostlek]

Like I'm not a lawyer, but the base of the integration was Apache 2.0 in the core repository, which you used as a base for these changes. You're free to use a different license for later commits, but you can't change the license of the base, unless you have permission from all the contributors?

[joostlek]

I'm all for moving fast and making sure we get fixes in as quick as possible, I believe you once mentioned that everything could land in the September release, which isn't that far away from now

[janiversen]

No I cannot change the license for that base, only for the new commits, which is exactly what I want.

My hope was the September release but seeing how slow the 2 current PRs are moving, I think it will take a lot more time.

[crug80]

As final user, I'd like to see a smoother development of the core component, instead to spent my time switching between core and custom components. The latter could be common if I am a developer and probably that's what we everyday do before to submit a PR, but it is not a good scenario for a final user, IMHO. Probably the risk to see users migrating to a custom component is high and that could create more issues than what it wants to solve.

To know why modbus core component has still no maintainers is not my business, but I suppose that is the main way to have a reactive development process and aligned to the issues present in the queue is to work on the normalization of the development process putting the diplomacy and the project on the top of the problems queue.

Additionally, ahead to the jan's PR, there are also 2 contributions from new users which have an impact on the modbus core component and where a person with a clear idea on where the component should move could help to review and fix.

[janiversen]

I get your point, and most users can and should stay with the core component and in time will have exactly the same functionality, but with our current development/release process it means a user might wait months before he/she can test if the problem is fixed, and if not fixed have another long wait. It is important to notice, this is only an OPTION to speed up bug fixing/verification.

Right now there are 2 PRs open #150526 and #150581, they have only been open 3 and 4 days, which is no time compared to a lot of others and I am not complaining, but I am no longer expecting to have the bigger problems merged in time for the September release.

I never suggested this as a solution for all users, it is NOT. It is only for experienced users who report a problem and are willing to help see if the problem is fixed. Please remember the component exist and will continue to exist as long as there are a queue of PRs waiting (it will eventually not have any content) !!! the only question is if we tell users directly and give them a real possibility to test if their problem are fixed. The users can always get the information indirectly (via google, forum etc).

I think you are confused about the difference between maintainers and codeowners....I am currently maintaining modbus, so I do not understand your statement "has still no maintainers", or are you saying that my PRs are not maintenance ?

I have seen the 2 contributions, which both makes a lot of sense, but I have also read your comments about it would be better to make 2 entities, which seems to have stopped the development, I assume because it is a quite different (and from development point of view more complicated PR). The discussion whether the simple solution is sufficient or it should be 2 entities, is a user experience discussion, and really have nothing to do with development, and you as an experienced users seems to have decided, so what more do you expect more on those 2 PRs ? Who will spend time reviewing code, when the solution is discarded ?

[crug80]

Jan, I exposed only my personal consideration about this way to work and if in the past we never had the need to a have mirror custom component it means that a different approach could be replicated also in this present time.

I think you are confused about the difference between maintainers and codeowners....I am currently maintaining modbus, so I do not understand your statement "has still no maintainers", or are you saying that my PRs are not maintenance ?

Replace maintainer with codeowner or with "main maintainer" if it makes clearer what I said.

I have seen the 2 contributions, which both makes a lot of sense, but I have also read your comments about it would be better to make 2 entities, which seems to have stopped the development, I assume because it is a quite different (and from development point of view more complicated PR). The discussion whether the simple solution is sufficient or it should be 2 entities, is a user experience discussion, and really have nothing to do with development, and you as an experienced users seems to have decided, so what more do you expect more on those 2 PRs ? Who will spend time reviewing code, when the solution is discarded ?

I think that in both of PRs no solutions have been discarded and I'm not the person having the authority and the knowledge to approve/discard a PR.
I remember my first PR on modbus and your comments about "boiler plate code difficult to maintain" Vs user experience and I think that both of those PR should be evaluated considering both of the matters: code and its future maintaince and final user experience. I'm in HA from less than 2 years, so I don't consider me as an experienced user who can expose a final judgement on a PR, so I hope that you or other core members will evaluate them.

[janiversen]

Just one comment, right now there are 9 Pull requests (2 submitted) pending I believe that calls for different measures....in the "old" days we normally had no more than 1-2 Prs in a HA release so there was no need for special measures.

Anyhow the question is not whether or not to make the custom component it is already there and I expect it to be active at least the rest of the year. The question is how to inform users.

Regarding the 2 PRs, please do not expect me to chime in on whether or not 2 sensors are better......in the old days, I had probably merged both long time ago with some minor changes.

[janiversen]

Thanks for feedback.

[crug80]

You're welcome Jan! :)