Roadmap / Coordination to ez-wbc 2.0 #163
Comments
|
1 - Make RD's Image Builder script work to generate a working image. (@RespawnDespair/@user1321) -- WIP --
2 - Transfer the code used to generate this first image from RD's github/projects to bortek's github (in a new branch).(@RespawnDespair/@bortek)
3 - Give the 2.0 version number to RD's Image Builder last version script, and duplicate it 4 - Add new features from others images.(@ALL)
|
|
This looks excellent @Yes21 . Any reason why it is closed? |
|
Here is the first draft for a a technical roadmap for a good coordination of the revival of this great project. Don't hesitate to criticize it, to not agree it, to gives your remarks, to propose corrections, ... I've perhaps not good understood some technical steps. I will update the previous post as many times as needed, until it's ok for everybody. Thanks for your returns. |
|
That looks great! I can't find anything obviously wrong with this roadmap! |
|
This is excellent! I feel the scope is ambitious yet doable. |
You're right. This first draft is focused on the first steps, which could take a few more time. You can, now and here, propose in which new feature you want to involve yourself. Thanks for your comment :) |
|
Liking the proposition a lot. Thank you very much Yes21.
May I ask to have a look at the proposition about "Compile flags/switches" again at the end of last (closed) threat? #155 (comment)
I think we have to also prepare to see more Add-ons and Extension in the future that might not all fit into a "one size fits all" image. Now is the time that we can prepare for that by considering this in the design of the build pipeline.
Thank you very much :-)
Von meinem iPhone gesendet
… Am 17.10.2018 um 19:53 schrieb Luke ***@***.***>:
This is excellent! I feel the scope is ambitious yet doable.
After everyone comments and assuming this moves forward, whats next? Milestones? Volunteers and assignments?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@careyer |
|
@ALL I can suggest : 1.6RC7, 1.7RC1, 2.0RC1, ... Give your opinion, or suggest anything else. Thanks for your participation. |
|
@Yes21 I just can't stick to a RC (release candidate) i would say first release 1.6 with the mAh, time, distance osd features and than start development on 1.7 and when you have some major features like the ability to add add-ons, extentions or whatever you want to call them you call it 2.0 |
|
@cyrilknops Ok, I can understand what you mean. |
|
Yes 1.6 sounds good, keep it ez ;) |
|
I vote for 1.6 |
|
Yes, let's finish that thing first: 1.6
Von meinem iPhone gesendet
… Am 18.10.2018 um 07:35 schrieb Bortek ***@***.***>:
I vote for 1.6
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Might i add the possibility of tracking everything right here on Github? For example i did the same for my repository: |
|
@RespawnDespair : I think this is an excellent idea! Go ahead and do so (if @bortek does not veto) |
|
@Yes21 could do this for this repository, i don't want to mingle here as well. I have the image builder to worry about for now 😄 |
|
According to the majority, the next version will be 1.6. |
I just did it. Will see later how to add tasks ... |
|
I have taken the liberty of adding some default columns and added my task with a reference to the image-builder project. Feel free to add more notes/issues. |
|
I didn't there was projects tab on Git. This is excellent, we can then create cards here, no need for Trello. 👍 |
|
It seems that we can learn many things from each others. That's the good thing of collaboration or cocreation ! |
Yes21
changed the title
Yes21
changed the title
|
I have implemented the point 3 for myself. OSD with 3 screens on a rc channel, listening on SERVO_OUTPUT_RAW ( #36 ). I do not know where I could commit the changed code. Furthermore, I have created a fancier icon font ... |
|
@zenuavsolutions You could create a pull request here, but you should firstly coordinate your efforts with @careyer , because he already has code for the same function ... Ps : Your ground station seems awsome !! |
|
@zenuavsolutions : Your GCS looks awesome. Indeed the changes from dino.de already include "Ground Switches" and "AirSwitches". With "GroundSwitches" you can trigger arbitrary functions at the GCS. (what is best: it does not occupy any precious RC-Channel because it can read switches from e.g. Taranis that are not assined to a RC-function - Taranis has up to 32 switches ;-). What can you do with that?
With "AirSwitches" you can either drive GPIOs at the AirPi (hardware actions) or trigger e.g. a script (software actions). Again this does not occupy any precious RC-Channels ;-) Can you contribute some information about your GCS to the wiki maybe? P.S: Nice Kopter die du da baust ;-) |
|
Should I add these to items as 1.6 new features :
? |
|
@ALL : Okay guys! We are approching (with big steps) our first stable wifibroadcast-image-builder generated "official build". Thank you for everybody who is working and testing hard on this!!! You guys rock! Once we have this stable build we should agree on a concept on how to handle further AddOns/Improvements I have long time been thinking about this and lets face it: Over time more and more AddOns/Improvements are going to come and while some might happily live in co-exitance with each other, others might not be compatbile with one another. So we need to find a way to allow for that. Here is my suggestion: Core:
Addon:
Examples for AddOns are:
For the Addons we should agree on a concept how to let the user choose which functionalities he wants to use. This can either be done with software switches in the wifibroadcast_1.txt config file, e.g. or we could add command line options for the build.sh script by @RespawnDespair . With those command line options the user would be able to choose which addons are compiled into the image, e.g.
Any opinions/thoughts on this are welcome! What is your favourite conecpt? |
|
@careyer : I agree with your proposition. |
|
@ALL The first stable image appears in sight yes, lots of testing and fixing to do, but now i feel closer than ever. For EZ-WFB we need to redesign from the ground up for 1.7, this might seem dramatic, but it really isn't. Once the basics of this rewrite is done (really, don't be scared, i'm not overcomplicating things) moving forward will be easier. The architecture can be made so it will be possible to have everything in the base image and then easily switch things on and off by config. Although i've made the image-builder script as easy as possible i still feel it's something 'for us' to create 'offical' images and for advanced users to contribute to the project. So compile flags and the likes would probably alienate a lot of users. The config route as mentioned by @careyer has my absolute preference. Some of you might know, but i am a software architect by trade, my background is not in Linux/C, but some concepts of my job and experience are not related to OS or programming language. If the above comes across as me bragging, i apologize, this is not my intent, i'm also not hijacking the project, i just want to take a very active role in getting the technical aspects of this project on the right rack so it is possible to maintain quality and concistency while having multiple people contribute. |
|
@RespawnDespair you are exactly what what this project needs! The code needs to at least be organized and cleaned up so it’s at least maintainable. Then second big priority is to make it approachable to new devs where it can be expanded upon and improved. You are right that Wolfgang did a lot of things right with Dronebridge, I wish he would have organized wbc with a library before he went off in his own direction. I believe you are right that it is python with dronebridge. Ideally things would be open enough where ppl can build plugins easily AND contribute that code back to the project so that others can easily use it. Basically plugins that play well with others plugins. What we want to avoid is ppl creating one-off images (they needed a plug in option) that are only good for their one unique application and not compatible with other users code. Thanks for all your hard work! It’s exciting to watch it come together! |
|
+1 for what Luke just said.
@RespawnDespair : AWESOME WORK!!! I am happy to hear that you liked my idea and thoughts. We surely must reorganize things a little. Every smart thoughts that we put into the design now will serve us well in the near future and help getting the project to grow and stay maintainable.
Von meinem iPhone gesendet
… Am 02.11.2018 um 00:43 schrieb Luke ***@***.***>:
@RespawnDespair you are exactly what what this project needs! The code needs to at least be organized and cleaned up so it’s at least maintainable. Then second big priority is to make it approachable to new devs where it can be expanded upon and improved. You are right that Wolfgang did a lot of things right with Dronebridge, I wish he would have organized wbc with a library before he went off in his own direction. I believe you are right that it is python with dronebridge.
Ideally things would be open enough where ppl can build plugins easily AND contribute that code back to the project so that others can easily use it. Basically plugins that play well with others plugins. What we want to avoid is ppl creating one-off images (they needed a plug in option) that are only good for their one unique application and not compatible with other users code.
Thanks for all your hard work! It’s exciting to watch it come together!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Very good proposal careyer and good idea with restructuring of the code RespawnDespair, this is indeed necessarily. Regarding addonns I personally would prefer option1 for switching on/off the addonn. From user perspective this is mich easier than keeping editing ling command line. Moreover having some sort of gui where users klick and bock on/off the features which result in a downloadable file (with all options) that than just need to be copied to boot partition. It's an extra component to maintain, but perhaps makes a life of non advanced user easier. Something to consider inntge future. @Yes21 feel free to do update task list with ideas from this discussion. If we can benefit by moving some startup scripts to systemd then yes. This would at least be cleaner and more aligned with modern way of doing things. |
|
Getting off on a tangent but I remembered everything used to be systemd and then when Rodizio switched it to .profile. A quick search revealed this quote from Rodizio “I deliberately put everything into .profile because it allows to easily have everything running in the foreground (on the different ttys) and everything is in one place. With systemd, a lot of different services would run in the background and everything is cluttered over many scripts which have many redundant parts and are hard to maintain and keep in sync. The other reason is, I think for our purposes, systemd (and a full linux distribution like Raspbian) is just unnecessary bloat. Rangarid has already started a buildroot image for wifibroadcast, there we don't need all this systemd and init stuff. We can just run everything from inittab for example, without the need for systemd or a system-v style init system at all.” personally I found systemd easier (maybe because that’s what I was used to). I think the difference was really just a preference for Rodizio and had little to do with performance and reliability. |
|
@pilotnbr1 I remember also, i agree with his explanation, not with the current implementation. The .profile script is a hardly readable goliath. Separating it into separate scripts is not much better (as i have done). As to using buildroot, this was what i did before doing the image-builder. The downside at the time was that it targets exactly 1 architecture. You'd have different images for Pi0, Pi2, Pi3 etc. At the time we wanted a 'one size fits all' image. Maybe in the future we will reconsider and make platform specific images. For myself i have more insight into what actually 'makes' EZ-WFB work, so revisiting the buildroot might be possible. As we gather more people in the project with specific experience (you yourself seem very knowledgeable in regards to Linux) we open possibilities to redesign parts of the system. Rodizio ran this as a one-man-show and he did an amazing job, but i feel the project needs the input and experience of more than one person to truly deliver on its promise. I'd love to get together (virtually) with the core group and discuss such subjects... |
|
Regarding the version: The roadmap however shows that the release is based on a not much tested image builder which still seems to have many issues and there is a completely new Raspbian release as well as completely new Kernel and Raspberry firmware being used. These are very large and major changes, that should be released as 1.7beta1 or something like that first, then later as 1.7 final. Regarding systemd: Also (like I have already mentioned), systemd is just unnecessary bloat for our application. We don't need to start a lot of different daemons and also we don't need all the additional functionality (like logging for example) it provides. It just adds complexity, adds another dependency (i.e. another piece of software that can have bugs, that can change it's behaviour in unintended ways for our application, can break our application due to syntax/config changes, will make it less portable to other systems, etc. etc). What's also not nice about it is, that some functionality cannot be easily and cleanly (or not at all) disabled, I remember disabling logging and other stuff was a pain, I had to delete stuff because it couldn't be cleanly disabled. Another issue with systemd is: It causes a long delay (5 or more seconds) on the Pi1/0 right before the login screen for some reason, without systemd, bootup would be much faster on a Pi1/0. In short: Really, don't use it. |
|
@rodizio1 I'd love to chat with you on this subject. Edit: Also yes, using 1.6 might just add to the already exisiting confusion. 1.7 Beta might be better. |
|
Yeah, chat might be a good idea. Do you have something setup already? |
|
I just made a gitter chatroom, never tried this before: |
My first propositions were here. But the majority did choose 1.6 ... If you accept that 1.6 will never exist, so I vote for 1.7 (with betas before stable). |
|
I think 1.7 would be better, or to completely separate the efforts 2.0 even. With beta-1 as the first official release. |
|
Yes, Rodizios' considerations are absolutely legit. 1.7b1 or 2.0b1 would be more appropriate.
Von meinem iPhone gesendet
… Am 04.11.2018 um 15:26 schrieb Jelle Tigchelaar ***@***.***>:
I think 1.7 would be better, or to completely separate the efforts 2.0 even. With beta-1 as the first official release.
We changed the kernel, drivers, code, almost everything is different from 1.6RC6...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
I'm now for 2.0beta1, because that's now a new life cycle for EZ-WBC ! |
|
@ALL |
|
It's not that important if you ask me but if I would choose between the options you listed I would select 2.0b1 since there are so many changes going on right now. We were trying to build what was supposed to be 1.6RC6 but will end up a lot further :) ....when we have it stable. |
|
+1 2.0b1
… Am 05.11.2018 um 20:43 schrieb Bortek ***@***.***>:
It's not that important if you ask me but if I would choose between the options you listed I would select 2.0b1 since there are so many changes going on right now. We were trying to build what was supposed to be 1.6RC6 but will end up a lot further :) ....when we have it stable.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#163 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF3v29lKw5PS6JPHYJUHxAwFecY8KHJpks5usJTEgaJpZM4XkDok>.
|
|
Ok, let's go for 2.0 beta1 |
Yes21
changed the title
Proposition of Roadmap / Coordination
The text was updated successfully, but these errors were encountered: