Explanation of Fork

[dahlb]

WARNING: likely boring and only meant to help clarify those who are concerned about drama.

I initially got into this integration because my toddler needed diaper changes in the winter and I needed a way to keep the car warm for their comfort, without leaving the car unlocked and running. I started by using https://github.com/fuatakgun/kia_uvo but found it frustratingly unreliable. I wrote the US Kia implementation from scratch and threw in some other improvements in the two weeks. But ran afoul of that repos maintainer's goals not aligning with my need to reliability or my needed pace of ASAP due to my real work use case. When I started this fork is was a green field re-implementation . I did it in 10 days as a single commit to attempt to preserve any git annotations for code that survived the green field rewrite. The main problem turned out to be related to time zones, I feel lucky that a friendly dev helped me port that back to a repo I was no longer welcome in. Since it was a rewrite free of legacy restrictions I tried to improve any pain points I encountered or best practices I learned from HA's core and documentation in my first two weeks. I feel this projects clean MVC helps ensure easy improvements without losing stability.

I initially was only going to make a rock solid stable implementation for US Kia because that's what I needed. However after seeing numerous issues generated on the other fork that I had already resolved I opened tickets on this fork about adding support for other region/brands, when I got the first response I decided I might as well support them as I have a good amount of free time and this project is simple yet useful; aka fun. I think a competing implementation can be healthy for the community, in the short term it was already clearly provided the old fork with much needed energy to get back into contributing. It would be nice to know these improvements are benefiting others, but my main goal is still the same to ensure this is a rock solid integration. That generally involves rapid development with fast features, if you find a version that works for you and want that stability don't use master; stick with the version that is working for you.

When I signed off that repo I told them I planned to no longer interact with that repo as I recognized the obvious interaction would be to point users to this fork which has better code. I wrongly didn't stick to that plan once after being repeatedly pinged by that repo's owner culminating in my being banned for this advice post, suggesting a 2 line fix to an open ticket I was pinged on and if that port was too complex for the maintainer, to just use my fork which already has that fixed. I should've known better and kept to my goal of not posting again on that repo, but being banned and prevented from watching the repo to ensure this fork benefits from all the community provided feedback is petty and reminds me why I forked in the first place.