custom-components
🚩 Missing admin and migration to HA core
I have some bad news. I am the effective lead for this integration, yet I'm not admin of this repo. I've not been successful in reaching out to @Hellowlol which I think might have admin rights. He was the one to promoted me to collaborator and is the original creator. I don't know if there are any other persons having admin rights for this repo because since I'm not an admin myself. I cannot see who else have what privileges in our repo.
I have been attempting find anyone that might be admins for the custom-components organization that might help out. I've been reaching out in the HA community on Discord without any success. I've received negative feedback from one central user that we suspected were admin.
The feedback is that we won't be able to get admin right for this repo and that custom-components is probably abandoned. We (and HA) don't know who is responsible. The recommendation I received is to fork the repo. If we do that we'll lose all issues, pull requests and releases. To me this constitutes a major risk, because if I'm losing access to this repo, we'll be cut off from the continued development of this integration.
The recommendation from @joostlek (HA) is to start the migration into HA core. This way there will be more people helping out on keeping the infrastructure and we avoid situation like this. We this discuss this topic some time ago in #129 where the interest wasn't that great.
For that to happen, we need to split the Zaptec facing API parts into a new access library which is published on PyPi. This means we must figure out where to store that repo and the ownership for it, both on GitHub and on PyPi. And we need to ensure that we don't get into the same situation we're in now. We'll need to outline in more detail what the steps to a migration to HA requires in another issue.
@steinmn
My personal opinion is that I think it's time to consider the migration to HA core. I think it outweighs the risks we are facing in our current project. We have refactored the integration in a way that is in accordance with the rough outline with the structure in HA. We're not quite there yet when it comes to the quality scale, but it shouldn't be that much work.
What worries me the most is to have the time available to commit to a migration like this. I do not know what maintainership in HA core actually involves with respect to time and effort. I have a day job that takes a lot so I'm afraid to promise something I cannot keep. It would help a lot if we were at least two people. Lately we've been two devs for the bugfixes and releases, which has been wonderful. Thanks @steinmn for that.
On a secondary note, according to the analytics from HA here, we have 956 documented installs of zaptec. Given that analytics is by default tuned off in HA and that its estimated that 1/2-3/4 of the HA users never turn it on, its plausible that we have an install base between 2k-4k installations 🎉🎉
This makes zaptec more than eligible for inclusion into HA core.
What worries me the most is to have the time available to commit to a migration like this. I do not know what maintainership in HA core actually involves with respect to time and effort. I have a day job that takes a lot so I'm afraid to promise something I cannot keep.
Like you @sveinse, I also have a day job that leaves me with limited time and/or brain power left over to devote to this. I definitely want to contribute to migrating, but I'm also hesitant to make too many promises.
This means we must figure out where to store that repo and the ownership for it, both on GitHub and on PyPi. And we need to ensure that we don't get into the same situation we're in now.
I think this ☝️ is the most important part right now. Are there any recommendations/best-practices from HA on how to best set up ownership/access to the access library on github and pypi in order to future-proof against abandonment @joostlek?
To me, the logical next step would be a 0.9.0-version relying on a new pypi-access-library, and we start moving all discussions that make sense to the repo for the access library. Having watched the migration of the volvo integration from hacs to core from the outside, it can take quite a bit of time for the complete migration. There will be a time period where the core integration has very limited use, since each platform (sensor, button, switch...) is added separately. I think having this in-between step would make it easier to keep the hacs-version functional with minimal effort until the core version fully covers the usecases.
On a secondary note, according to the analytics from HA here, we have 956 documented installs of zaptec. Given that analytics is by default tuned off in HA and that its estimated that 1/2-3/4 of the HA users never turn it on, its plausible that we have an install base between 2k-4k installations 🎉🎉
This makes zaptec more than eligible for inclusion into HA core.
Really cool! Couldn't resist plotting the numbers to compare against the HA core pie chart, and looks like the zaptec integration users behave a lot like the average HA user: About a third on the newest version, a little under half on one of the slightly-older-but-not-hopelessly-outdated versions, and the rest on older versions.
This means we must figure out where to store that repo and the ownership for it, both on GitHub and on PyPi. And we need to ensure that we don't get into the same situation we're in now.
I think this ☝️ is the most important part right now. Are there any recommendations/best-practices from HA on how to best set up ownership/access to the access library on github and pypi in order to future-proof against abandonment @joostlek?
Agreed. I'll do some digging to see if I can find some best practices and examples what other projects does.
I was thinking setting up a new GitHub org dedicated to this integration and repo(s) under it. We become owners and developers in that org.
This was actually my initial plan if we were able to acquire admin for this repo. Regardless if we do HA core integration or not, we definitely want to get off custom-components. A repo admin could do an ownership transfer of the new org, which would include issues, prs and releases.
To me, the logical next step would be a 0.9.0-version relying on a new pypi-access-library, and we start moving all discussions that make sense to the repo for the access library. Having watched the migration of the volvo integration from hacs to core from the outside, it can take quite a bit of time for the complete migration. There will be a time period where the core integration has very limited use, since each platform (sensor, button, switch...) is added separately. I think having this in-between step would make it easier to keep the hacs-version functional with minimal effort until the core version fully covers the usecases.
Yes, I agree. We can start with experimenting with an access library on the side even with the setup we have.
You're also right that a migration to HA core will take time. They want one PR at a time, with one file/feature one by one. And I understand it will spend some time in review. My thinking was that we keep this HACS integration going in parallel until HA core migration is feature complete so we don't leave the users without an option. IF we are to do this, we need to it in a tempo we're able to and comfortable with.
Nothing is decided yet, but a migration could be staged something like this:
- Fixup the interface between the API parts and the HA parts. I'd definitely like to clean up the snake_case vs Zaptecs PascalCase before we split.
- Move the API parts into a suitable access library and adopt the changes in the integration. 0.9.* is a good place for that
- Fork/tag zaptec and start the lengthy PR process to HA core
- When the zaptec integration in HA core is at MVP, we can announce it and recommend our users to switch over.
Something like that.
I'm following the developments with great interest. If I were a programmer, I'd be happy to help, but I'm afraid I won't be able to add any value to the migration to HA core.
Are there any recommendations/best-practices from HA on how to best set up ownership/access to the access library on github and pypi in order to future-proof against abandonment @joostlek?
Automate it :)
Like yes you can make an org for both github and pypi, pypi org might take a while before its approved. But you also have to wonder how much is overkill. I have some people who I trust added to my libraries and they can merge and release themselves. Yes that would be a problem if I fall away and they want to add another one, but at that point they could also fork it (and at this moment in time I don't expect myself to fall away)
I'm following the developments with great interest. If I were a programmer, I'd be happy to help, but I'm afraid I won't be able to add any value to the migration to HA core.
We are always in need for testers, so there's things you can contribute with even if you're not a programmer. This is particular important in this integration since we don't have any insight into Zaptec's behavior in the cloud. The only means we have is to physically test it on a real system, so more people willing to test alphas/betas is a huge help!