Yio Remote Community

What is going on, everybody on vacation?

@Marton @zehnm @Nklerk

What is going on ? There are nearly no activities since 2 month. Currently the progress is close to NEEO experience …

OK, I have a working YIO-remote and I can finish the things I need in my own fork. But this was not my intention. I have all functions I need implemented in a PWA running on all my devices. The only motivation to take part on the YIO development was to create something for the whole community.

I implemented a LOGGING system which was very well received at the beginning. Now 90 % are part of the current version but not usable because of the missing 10 %. Nobody can use it as it is, and my proposals are ignored since months.

I implemented a ROON integration which is ready for testing but the required “generic browsing UI” is missing. I proposed to add my UI solution but it was declined. Why ? When Marton implements are better version, it can be replaced.

The most important advantage of the YIO solution compared to a smartphone app is the usage of the hardware buttons. But they are not consistently supported in all UIs.

There are some general things wrong with the project :

The github workflow is unnecessary blown up even for integrations which are developed by one person.
If so few people are working together and the whole project is in such an early state it is sufficient to trust that the 2-4 people are not making changes which are breaking the compatibility. It is unacceptable that an integration implementor is not in control of his repository.

Modularisation of the integrations is well organized but when an integration requires a specific UI we have to wait until Marton integrates it. As the UI modularisation is not so easy to implement, it is necessary that integration implementors can inject UIs and entities easily as long as they are not breaking functionality of other components. At this point, it is not possible to find a common solution without communication and trust.

It is the most important and complicated thing of YIO development, to find a common abstraction (entities, UI) supporting different integrations. It requires a lot of communication, I think.

But I see also positive things:
Remote-os, web-configurator is great, I wouldn’t have the know-how to realize that.

2 Likes

@ChristianRiedl I can’t speak for the others, but I am actually on vacation.

It seems like people tend to forget that we are doing this project next to our work and family lives. NEEO was a company working on a product. YIO is an open-source DIY project. I’m not sure it’s fair to expect updates on a regular basis knowing everyone is offering their free time for the project. We are doing what we can, but obviously life can happen.

You and anybody are welcome to submit pull requests to the repositories for improvements. Unfortunately there were not many. The github workflow is setup the way it is, because it’s prepared for more contributions. But I’ll leave the explanation to @zehnm.

I think communication is key to collaboration and I don’t have any problem with finding solutions by communicating. This is a collaborative effort and I think it’s crucial to discuss ideas before jumping to implementation.

I’m glad that you found positive things in the project :slight_smile:

@ChristianRiedl What is happening? The usual, besides covid-19 or summer vacations.

Development is continuing, lots of things have been discussed on Discord during the last months.
I’ve written a webhook integration, which is currently being tested before it will be moved to the YIO GitHub projects. It has been announced on GitHub and Discord.

Logging has been discussed in the GitHub topic. The next major remote-os release with updated Qt will have journald as logging backend. This will make the log files obsolete.
For enhancements or changes we need pull-requests:
https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/proposing-changes-to-your-work-with-pull-requests
That’s the main reason why your enhancements are still not integrated. I’m not going to cherry pick them. Please open a pull request, then we are also able to discuss any issues directly in the source code. GitHub has a really great pull request work flow!

What is unnecessarily blown up with the GitHub workflow? That we have automatic builds with automated releases including release notes? Or automated code checks? I don’t think so. Would you rather have everything done manually, with local builds, manual uploads, and no idea how a particular build has been made?
If something builds on a Windows machine, it doesn’t mean it works on Mac, Linux or ARM. All that is done with GitHub workflows. I simply hate doing stuff over and over again manually. It’s a waste of time, no fun at all and prone for errors.
We have already simplified the Git Flow process to the much slimmer GitHub flow: https://guides.github.com/introduction/flow/
This is a very common collaboration form, not just for open source projects.

The YIO project depends on contributions from its users, otherwise it is only going forward with what the core members are able to accomplish. As Marton already said, communication and collaboration are key! Otherwise there’s a good chance that things either won’t be accepted or need rework before they can be integrated. The best place to do this is with a GitHub issue, especially if the technical details are already known. For concepts and ideas this can also be discussed in this forum.

1 Like