Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upDiscussion: Future of Phoniebox #774
Comments
This comment has been minimized.
This comment has been minimized.
|
I'd like to notify and invite at least the six most recent contributors (Micz has been mentioned in the post above) to this discussion: |
This comment has been minimized.
This comment has been minimized.
I think one repo with sub directories for each component is fine. Phoniebox isn’t that big and I think different repos adds another level of complexity, which could be hard to integrate in a working product.
Different sub directories with maybe directories for common stuff could work. Adding (automated) unit tests for each component could be added more easily as a separation in components forces clear interfaces.
I think the current workflow is fine in general. Alternatively we could use GitHub Flow, which is very lightweight. Master is always deployable and each feature/fix branches from master and after review/test is merged in master.
I think something like Gitter, Slack or similar could help for quick questions and discussions of ideas.
I think, if we try to add more tests like @veloxidSchweiz has already started (and automate them with Github Actions), we become more confident that changes don’t break the product, so @MiczFlor doesn‘t need to review and test everything so thoroughly.
Yes, I’m really interested what plans or ideas exist.
Difficult question :) |
This comment has been minimized.
This comment has been minimized.
|
Hi, because you asked me to give my opinion:
I agree with @s-martin to keep the Phoniebox in one single Github-repo. In the past weeks I've created two pull-requests and was able to understand the functionality of the code within some evenings. If the code is splitted into several individual repositories, for people like me (with low/middle skills in php but some ideas) it could be harder to contribute to Phoniebox. Keep in mind that the project is focused on parents and childrens. If a more complex version is nescesary, maybe the repo can be forked to a "PhonieBoxPro" with enhanced functionality? It may then be justified to create a distributed repository. By the way: thank you for this wonderful project! |
This comment has been minimized.
This comment has been minimized.
|
Hi guys, this is the right thread, just at the right time. I took a little time to write up a few thoughts regarding Phoniebox. Possibly this should - eventually - become a small manifesto about the idea, progress, community and future of phoniebox? I believe the few posts above already illustrate the nature of the Phoniebox community. Generally speaking: I am very much open to the idea of sharing responsibility, giving access to merge and plan together. From the past (years!) of experience, I have seen great minds and coders come and go. So all in one place is a good idea, to make sure the project actually has a future. (I am also happy to have a Phoniebox meetup of developers in Berlin, if there are enough around. Any interest?) https://github.com/MiczFlor/RPi-Jukebox-RFID/wiki/Architecture_HowWeWork Phoniebox consists of code, a lively community and inspiring designsA Phoniebox...
How the Phoniebox community works
The Phoniebox code base
|
This comment has been minimized.
This comment has been minimized.
|
From my more abstract statement above, I deduce the following action points:
... what did I miss? |
This comment has been minimized.
This comment has been minimized.
|
I'd like to add: Adding first unit tests was already done in #763 (can't wait until that is merged). This could be improved step by step, maybe even for integration tests with hardware (mockups). If we can write a wiki article how to set up a test environment on real hw or docker, this could help many people and improve overall test coverage. |
This comment has been minimized.
This comment has been minimized.
I agree with this. If you look at how Google organises something like the NSynth project which has four different very definitely interconnected but also very different components (hardware schematics, audio pipeline, interface software, firmware, and PCB…) it's all separate folders each with a README but a root level README giving the overall information. |
This comment has been minimized.
This comment has been minimized.
This is why you force contributors to make forks with feature branches and create pull requests based on their suggested changes. I've seen some quite correct suggestions about master being always deployable and only merging after manual and automated pipeline acceptance testing. |
This comment has been minimized.
This comment has been minimized.
|
@s-martin great energy, a wiki article would be great. And how would you write https://github.com/MiczFlor/RPi-Jukebox-RFID/wiki/Architecture_HowWeWork How the Phoniebox community works...
... The Phoniebox code base
|
This comment has been minimized.
This comment has been minimized.
|
@MiczFlor I would love to join a Phoniebox group. Have you considered starting a meetup? It might be a good fit for the Embedded Linux or Linux Audio groups that already exist here in Berlin and have an active userbase. I could potentially do an introduction to some local hardware folks if you're interested. Alternatively there are the always excellent C-Base and XHain hackspaces who might be interested in hosting an event in exchange for exposure and beer money through the door. |
This comment has been minimized.
This comment has been minimized.
|
First of all: sorry for my late answer, my time in the early year is really expensive, but i look forward to invest the time i can give to this Project.
The basic Installation should be one repo in my opinion. I would like to see more repos, that can be attached like modules, maybe also as an installer. I also think, that config files, which will be edited manually, and also Shortcuts, Music, Playlists and so on should be seperated from the basic github repo in the installation. That makes it much easier to get an update working... But this is only my point of view.
First of all, we should think of a stable and actual repo. @MiczFlor this is in german, because i don't find the words in english: Das Projekt hier ist der Hammer und ich bin Dir dafür mega dankbar. Aber es ist in dieses Repo so viel rein geflossen, dass es sehr schwer zu überschauen ist. Nimm das nicht als Kritik, sondern eher als Verbesserungsvorschlag, dass man Modulbasiert verschiedene Repos anbietet.
The main problem is, that there must be a main developer and tester for each step. One problem is also, there are maybe only two contributers, but both checking in to develop. Maybe it is better to make a repo like develop_username_timestamp? I am not sure, this is not easy for @MiczFlor to handle.
If there were different developers that organize the developent: yes. At this stage, i think no, because contributers are coming and going. There a just a handful of developers here about months.
Ask @MiczFlor
This would be a nice plan! But you need main contributers always working for this project, not just for a couple of weeks.
Do you have an example. So, i orderd three more Pis, i will build three more boxes to test. I hope, the project goes on and i try helping as much as i can. |
This comment has been minimized.
This comment has been minimized.
|
Hi, Here some personal opinions from my experiences. I am not a full-stack developer (whatever that means), but I already worked in some software projects from different perspectives.
I am not an expert on running docker on RPis, but if there is possiblity to containerize the functionalities this would probably allow a very easy deployment.... One would run separate containers for each subject of concern and it would be quite easy to update single compontents... here i would suggest to have one for the html interace, one for the mpd (or one of his spotify sisters), one for the control of the RFID reader, one for the gpio handling (maybe one separate for the oled display).... By only 'mounting' the music- and setting-directory, the system is very likley to be good upgradable. This is only my personal view and I am open for such a discussion. Having such an open-source-project in which many people invest a marginal time of their free time is really great and I love this projects, If I can show my acknowledgement by contributing this is even better ;-) |
This comment has been minimized.
This comment has been minimized.
|
Thanks for the input, this is really cool. Regarding the code repo: I agree with ...
I know what it's been like to answer questions regarding other peoples forked repos who once posted a link to their file and then changed it a few weeks later to fit their specific, it didn't work for others and suddenly I had to take the heat and try to awake the contributor from the dead (who did great work, and meant to do good, and did). Then suddenly everybody was annoyed for no reason. I prefer people creating pull requests and merge to develop - then they want to be proud of their code, comment their code and I know it is tested (enough) even if I don't have the hardware (ok, sure @veloxidSchweiz this is not the type of testing you are talking about :) ... and would like to restructure the folders and rename the files to make it easier for new people to dive into the deep end. In terms of components or functionality, and following @ZyanKLee list in the first post, I think these are the "folders" we need - not sure how to name them... (what am I missing?)
Any suggestions for naming and folder structure? I started this document in the wiki, please put suggestions there (the wiki might be the more collaborative editing space) |
This comment has been minimized.
This comment has been minimized.
|
First of all: I'm glad this discussion was so well received and on time. :) After @MiczFlor's latest post I thought about how to go on from here with his plan while avoiding any interruption to the installation of new Phonieboxes and came up with this idea: First of all, I think that new github feature "projects" might come in very handy to organize the planned steps and workpackages without us cluttering up the main issues too much. To also separate the code from the "legacy" system, I would suggest a new long-living branch with a similar name; i.e. "reorga". This is an attempt to illustrate the git flow: The |
This comment has been minimized.
This comment has been minimized.
|
maybe you can change the phoniebox software so that it can be integrated into the Logitech Media Center. |

To go deeper into the side-tracked topic about the code future on #763 I open this issue (as we are lacking an alternative communication method).
Yesterday I had a short look into the build, install and update scripts of LibreElec.tv - it left me barely any wiser after an hour reading through all the scripts, testing the build script and trying to figure how the heck the actual update of a LibreElec system works. (not the download but the flashing of the new version - what does it and where is that piece of code?)
Anyway: as far as I can see this project can be divided into some more or less separate sub-projects.
... did I miss something vital?
Questions: