First of all, thanks for the replies. Tackling all of them in one post to avoid multiple messages.
Why move these posts, and not others, though? What’s the criteria? How’s my reply different than others or more unrelated?
I follow the Open Source Way: Transparency, Collaboration, Inclusive, Community are some of the words that comes to mind
Fair, it could have been worse, yes.
Why move my perspective and not others’? My perspective, especially the first post moved here, it’s a direct response to the ADR-0010, or more specifically to the blog post itself. As such, I do not understand the decision and I do feel my opinion treated differently despite having invested time in reading and compiling all the messages, bringing arguments argued with data and examples, etc.
Also the blog post was moved as “YAML - cost of maintenance in custom components” which would make it uninteresting to people and completely unrelated to the actual topic. This is a thread about how I think the arguments given are debatable, and bring counterarguments, data and examples to it. It is was a conversation towards a decision with which I don’t agree.
“Hi Nito, sure thing. Because of the large amount of content in your replies (which is fine of course) I figured it best for you to have your own dedicated thread. The original ADR thread became busy very quickly, so having your own thread would help organize/consolidate your discussion. I didn’t actually make the decision to formally split the topic though.”
As per our Discord, thanks a lot for your reply. It is very meaningful to at least get an explanation. I reached out privately on Discord to actually discuss aside of the community. However, since you have brought it here, happy to bring my reply as well and continue here if needed.
My objective with those posts is to bring counter arguments to the blog post; bringing a different point of view. These arguments include pure argumentation, bringing some data, a summary of the whole thread itself, and code examples to showcase that some of those counterpoints are valid.
I personally do not understand why some people’s opinions are valid to stay on the post, but mine needs to be split. Discussions were happening already, so it’s definitely not to boost the discussion (specially since this has been moved to “Uncategorized” with an unrelated title).
All the opposite, it feels like we’re trying to hide and bring those counter arguments away from the main thread on purpose (that’s how I feel). And that’s not really nice thing, in my opinion.
Not saying that your post/reply is different than others. But keeping this together makes it easier to follow as you’re providing a lot of content on that matter.
It would have been easier to follow if it was on the original post, to which they are related and a response to. Nonetheless, this is not a battle I’m going to win, you’re moderators and I’m not. You have the power to hide my responses away, to support the YAML deprecation as if no one is opposing to it or bringing valid counterarguments.
On my side, I will continue bringing counterarguments and bringing to the forum that I feel most relevant.
For the continued ‘clarity’ of others reading this post. It has unfortunately been split from the important discussion titled The future of YAML. In the interests of maintaining a lasting connection to that lengthy discussion which was split here may I suggest that those posting future responces should consider posting links to relavent sections of that post so readers may easily refer back from here if required.
No point in arguing about the split anymore. Let’s focus on bringing good examples about YAML maintenance.
For those interested in officially addressing ADR, I’ve submitted an architecture issue to allow YAML configuration optionally. The arguments that I’ve posted on The Future of YAML (now here) have been brought to official discussion. Comments can be done there instead of here as that’s the official channel for these conversations.
I have also submitted another one with a potential solution which advocates for reusing the same schema, set up and partially rely on UI to solve most or all of the problems with the “cost of maintenance”. This is based on the experiments that were published in this thread. More experiments could still be positive, for the same or different approach.
There are also alternative proposals. If you have your ideas, you should also feel encouraged to bring them.
Well, it will be less encouraging when you read that they will “not (be) doing this. Or any of your (my) other proposal.s”.
However, this is the official approach to propose changes and everyone should be encouraged to do it. The owners of the project are on their right to decide what to do with those, but hopefully diverse perspectives and ideas can be heard; and, if we are lucky, we may hear the reasons for which those ideas are not worth pursuing.
I just had a look and it is much more like discouraging it seems. As a user with modest needs I will not be moving to new releases. Going forward from now means rapidly losing what you had…the owners can do what they like but I won’t be a part of it.
I am personally doing the same, but there are alternatives too. Custom components overwrite core components. As such, you can migrate your core components to custom components to maintain your YAML.
For example, on the PS4 component, what I did is to create a wrapper on top of the official component (full explanation). This has the advantage of having all improvement and updates that the core components has (incl. UI), but with the added advantages of keeping YAML support. The disadvantage is that it still requires maintenance as the schema changes without notification. The purpose of this repository is to get more and more people to do the same.
There’s another alternative, which might be faster. You can take a snapshot of a component at a certain time/version/commit and download it (see instructions). Then you can add that as a custom component and it would work as an old version. The advantage of this is that it virtually requires no effort, but the disadvantage is that bug fixes and improvements will not pass through. As such, it may create conflicts or stop working in the future.
Both of these are not a long term plan as I do not have guarantees that it would work in the future as YAML deprecation may be rolled out more aggressively. (Example, if they phase out the async_setup_platform which is needed for YAML configuration).
I am working on a post discussing this a bit more in depth, but I need more time and my current focus is on getting input on the YAML part from Architecture. The post will include other more radical approaches too.
I honestly love your work and your enthusiasm but IMHO…it will most certainly be aggressive!
Anyone here who has read/been a part of the PRO YAML posts will know that is the future unfortunately.
If lot of advanced users stop updating the core and add components as custom components, it will be easy to prevent that in future simply by making “essential” change in component interface.
Not saying it will be done, just that if this is thought as a game, that move will make using new components in old core harder.
There may be a few more than that I reckon David? But for me new integrations are simply irrelevant. What I need is a stable, secure and easily customisable product that is well documented and supported.
Next most important for me is being able to markup my config as I wish and wherever I wish.
I feel certain that I may not be alone in that desire but only time will tell there?
