Adding support for a new device and project direction

[rah]

Hi there,

Hypothetically speaking, if one wanted to add support for a new device with the intention of that work being accepted into RuneOS, how would one go about doing that?

The latest commits on the RuneOS repository were three years ago. There are forks of that repository, some with a lot of work invested but none of that work is being merged back into RuneOS.

There is talk about a new V2 version of the OS but it's not clear where that work is happening or whether it will ever materialise. According to hondagx35, there are unofficial releases of the existing version occurring from unmerged branches because of an expectation that some future V2 will appear. It looks like the work done in the unmerged branches is wasting away.

This kind of work on multiple branches is not unusual in collaborative free software development. The typical model is like so:

1. Have a designated V1 branch
2. Accept merge requests into the V1 branch
3. Make official releases from the V1 branch
4. Have a designated V2 branch
5. Accept merge requests into the V2 branch
6. Make development releases from the V2 branch
7. When V2 becomes stable and ready to supercede V1, designate V2 as the new official branch
8. Designate V1 as a legacy branch, continue accepting merge requests and making legacy releases until nobody bothers any more

See for example, JACK, Apache, GTK, Linux, etc., etc.

Coming to RuneAudio for the first time, the impression is that the project is in disarray which is a pity because it looks like an awesome system with very great potential. It seems like there is some work being done but that work is not being channeled into a collaborative effort and as a result, the energy being put in is not driving the project forward.

For a person looking to work with RuneAudio, this state of affairs is a serious problem. It's not clear what to build on top of. Which brings me back to the question at the start of this post. Usually the answer to that question is plainly obvious from git commit histories, some "developer" page, or whatever. With RuneAudio, there is no clarity.

I'm an outsider coming to this community and pointing out problems straight away without having done any work. I hope I haven't offended anyone, that's not my intention. The reason I've done this is because I see such great potential in the project but also I see an immediate barrier for anybody who might wish to work with RuneAudio in a way that can benefit the project. To me this post is work to possibly help bring down that barrier and in so doing, perhaps help the project move forward.

Regards,

Bob Ham

[ACX]

Hello rah,

As mentioned in multiple posts around the forum, we are currently working at the new v2, which is basically a rewrite of the whole system. Because of that, and also to avoid further pressures, we are bringing the development forward on private repositories, at least until the first alpha version will be out. Unfortunately we are working at a slow pace - our free time is low, life happens - but we are close to a first release.

I agree with you that we should be more transparent with the roadmap and to be better structured for collaboration. I don't know if the typical model you described is applicable here because there's a clear break between v1 and v2, so we decided to work on separate repos.

If you think you could help us on the OS side for this first v2 release, please PM me.

[rah]

As mentioned in multiple posts around the forum, we are currently working at the new v2, which is basically a rewrite of the whole system. Because of that, and also to avoid further pressures, we are bringing the development forward on private repositories, at least until the first alpha version will be out.

I don't understand, it seems like there's an explanatory step missing. Why does rewriting the whole system mean the repositories you're using to bring the development forward are private?

I don't know if the typical model you described is applicable here because there's a clear break between v1 and v2, so we decided to work on separate repos.

I used the word "branch" in the model but you could replace "branch" with "repo" and the same applies. The critical point is making official releases from the existing code base while concurrently developing a successor code base.

This is not only applicable here in RuneAudio but seemingly in great need. The fact that people are making unofficial releases on the forum from their own private forks is evidence of this. The fact that those releases are being treated as official further underscores the need. There seems to be no reason to refrain from making official releases from the existing RuneAudio code base.

If you think you could help us on the OS side for this first v2 release

I think you'll find that there are very few people, if any at all, who are interested in helping you. In general, people will be interested in helping themselves. If they can also help the project in the process of helping themselves then most will. However, the project (infrastructure, community, etc.) has to be engineered in such a way as to make that possible.

please PM me.

I don't understand this and in fact it seems strange to me. Perhaps you could help me understand your position? Why do you want to collaborate with developers over the Internet in private rather than collaborate with developers over the Internet in public?

I'm also no clearer on my original question: if, right now, one wanted to add support for a new device with the intention of that work being accepted into RuneOS, how would one go about doing that?

[janui]

Hi rah,

...I'm also no clearer on my original question: if, right now, one wanted to add support for a new device with the intention of that work being accepted into RuneOS, how would one go about doing that?...

This is a good place to start: https://github.com/gearhead/RuneOS/blob ... okbook_0.5
Please keep a logbook of changes and/or additions to the script. If you get your new device working and you are prepared to share your logbook we will try to integrate it into 0.6b. I can give you instructions for installing the latest UI and building an image for publication.
Somehow you will need to form a group of users who would be prepared to buy and support the new device, otherwise you will be answering all the user questions and doing the bug-fixing alone. Think carefully before you begin, it really is a lot of work.
janui

[rah]

This is a good place to start: https://github.com/gearhead/RuneOS/blob ... okbook_0.5

This isn't the RuneAudio repository.

If you get your new device working and you are prepared to share your logbook we will try to integrate it into 0.6b.

My question is about how to get device support into an official RuneAudio release rather than into a release of an unofficial fork.

I'll ask a question of yourself, as a member of the "we" who produce an unofficial fork: how come you haven't submitted any pull requests to the RuneAudio repository?

[Colin]

Hi Bob,

This isn't the RuneAudio repository.

I think that's the closest thing to making a RuneAudio (in the OS sense, not just UI) image for public release that I have found.

It's a shell script designed to run on a fresh install of an official Archlinux image and install RuneAudio on it, but it has a huge number of issues:
- lacks any error control,
- some parts are missing and must be done manually ("# ----->>>> DOWNLOAD PACKAGES FROM RuneOS REPO <<<<----- #"),
- all local packages are broken and must be rebuilt because Arch is a rolling distro
- the PKGBUILDs of the packages that must be rebuilt either point to git repos of software that changed enough to require more work to build, or
- other PKGBUILDs reference packages by an old version which doesn't work anymore on a more modern Archlinux install.

As you noticed, I tried to tackle some of those issues with my fork at https://github.com/colinleroy/RuneOS by using Ansible to make things repeatable. Other issues remain, because Arch is a rolling distro and as such, a moving target.
When I tried to regenerate an image a few monthes after managing to generate the first one using my Ansible playbook, things broke because Arch and phpiredis and I don't remember what else had moved, and I had to investigate the breaks (see commits on Jul 8: https://github.com/colinleroy/RuneOS/commits/master).

The main goal of RuneOS is to provide a distro with the necessary packages for RuneUI to work correctly on it ; and I think that for this task, Archlinux is an architectural choice that generates a lot of extra, tedious and unnecessary work.

In my opinion, RuneAudio should be based on a stable distribution like Debian, where work invested in configuring the underlying software can be capitalized on for at least a few years. Installing RuneAudio should not require any patch to any upstream package, but rather work with their various configuration files to set things the way they're needed.

In an ideal world, deploying RuneAudio should be possible using a distro image that has known software versions, and an Ansible playbook consisting of
- installing extra packages
- deploying configuration files from templates to */conf.d/*
- git cloning RuneUI.

This is quite a lot of work, I'm not sure that's the way Rune 2 is headed to because things happen behind curtains. That is, in my opinion, also a problem as it discourages potential contributors. But closed curtains or not, it's quite clear the persons behind the projects (plural, given the number of forks) are not very interested in welcoming contributions, as my lingering Pull requests show: https://github.com/gearhead/RuneUI/pulls

So for now, I've got my own little fork of RuneAudio with the extra features I wanted to see in it running at home, and stopped investing time perfecting it. I find that state of things quite sad, as I have a long history of contributing to the Free Software I use, but that's how things are. I don't have enough free time or will now to duplicate existing efforts by forking a whole ecosystem (website, forum, codebase, etc.)

Colin