Forking deviationTx

This has been suggested a number of times, and something I spent my recuperation thinking about. I've about decided that it's the right thing to do. But before starting work that would be unique to it, I thought I'd ping the community about it.

I've posted the goals and an early roadmap on my blog at rc.mired.org/ . If you want to discuss details of those, please do that there. I don't feel that the deviation forums are an appropriate place to plan a fork. On the other hand, if you object to the idea completely, or find that part of the plan would mean you wouldn't be willing to convert - that's appropriate here.

I know that's a fine distinction, but the discussion there should be about the fork, and the one here should be about whether or not the fork should happen at all.

Well, I'm united with myself, but that's pretty much the extent of it . And even going so far so as to suggest this has taken months of contemplation, so I'm not even that united.

Supporting the 7E and the standard GUI is the difference in goals I talked about. I understand your reasons for continuing to support both of them, but I'm not interested in doing so, and am tired of running into the 7E memory issues. Continuing to use firmware that's handicapped by needing to stay compatible with the 7E and a toolchain that's handicapped by the 7E memory limits simply isn't an option for me. The standard GUI isn't so much an issue for me - but my gut feeling is that until it's updated to deal with a modern models, it does more harm than good. Dropping it would keep the 7E builds working in an unsupported mode even longer than they do now.

I've created docker images for deviation builds, and would be happy to set up both CI (something I think we need) and nightly builds on them. But unless the CI results go somewhere where developers can see them and the build results go into the download area, there doesn't seem to be any point.

You didn't address any of the community issues I brought up. I agree that the community is small, so we should do everything we can to let the community support itself. Right now, even documentation that's crucial to deviation users that you wrote is hard to find for reasons I don't really understand. Stuff written by users is in even worse shape, no matter how good it might be.

I knowI'm just a newbie here (second post I think), but I think a newbies voice is of interest to those who will make the actual décisions...

I discovered drones at Christmas after having bought one for my daughter, (a Syma X11), and through the youtube videos found out that Deviation would allow me way more agility with it, as well as compatibility with a wide range of other drones and other RCed models.

With such a low price, the Devo7e was a no-brainer, which is why I bought a Tx in the first place. I WOULDN'T have bought a Tx that cost over 100 $/€, especially as I'm still a little bit solder-shy to do the mods, and would have feared for a higher investment. (Thanks SebyDocky for the youtube videos, they helped tremendously !)

I have no use for the standard GUI but being one that would be hit by a "7e-excluding fork", I understand how that could be bothering.

I think buying a Tx can be really intimidating, and creating a fork that excludes low-cost entrants would limit the fork to "specialists", and cutting out those from new entrants would be detrimental to all.

At the same time, I understand how the hardware limitations on the Devo 7e can be "shackles" for new developments, but fear that the cost would be too great for everyone here...

So if I were to vote, I guess it would be "no fork, pretty please..."

Sometimes it is hard to understand how things work in the code background or what parts do not.
This also applies to me as a technical person.

As far as I understood the simple heli mixer GUI is not even working for CCPM120 (Non-FBL) at this time (I have to test once more I rebuilt my heli) as the code is supplied as it is??!
www.deviationtx.com/mantisbt/view.php?id=624
www.deviationtx.com/forum/3-feedback-que...h?limitstart=0#44387

---

I do not like as well as that future / new features / changes / code improvements have to be left out just because of hitting Devo7E memory limits. This seems to completely stop further DeviationTX development and ongoing code merges??
What is the point in doing code development (Pull Requests) when afterwards you simply have to discard them because they might not fit? I believe I had seen that for 1-2 (bigger) code features?? Probably not very developer friendly...

For all this Devo7E memory trouble and blocking feature development I do NOT care in any way as a Devo 10 owner

---

This is even true for the feature "will moving sticks stop the backlight dimming or will they bring it back".
Was in code by accident, now removed (1 liner) completely and I would have to compile my own firmware to reactive stick dimmer wakeup.
Extending this feature to customization / configuration needs may overkill the Devo7E memory again.

---

Somehow I believe for the Devo7E we would need to take a different module route as you did with customizable forum 7e builds.
But that needs to be automated?! How? Can you mark / group code blocks into (selectable) modules and specifiy its size for a installer-tool?

A user might want to be able to choose what DeviationTX features shall be in or out to fit Devo7E.
And I mean by the user by an installer app on compile / install time.
So give the Devo7E user a list what features (and what size they take) they can choose in or have to leave out.

Wasn't that e.g the case for OpenTX Companion installer?
You select what you want, it compiles in background and you can install the compiled firmware in your TX.

----

Personally I would try to avoid splitting development into multiple projects if you can.
Probably it is too hard to bring parts of two worlds together (back and forth merging)??

Having to permanently install "developer" (nightly-build) versions on a TX for flying 450++ helis / bigger planes (non-toy / non-crashproof quads) is not a good solution either.

If allowed I also want to vote first to concentrate on to reinvent the wheel for the build and release management.


You may already know that once we step into more DSM / telemetry protocol changes and testing (Indigos test builds / code changes) for RC4.1-x.x.x. and always having to work on the developer default/trunk code and doing real-time flights from that might not be the best solution testing (ongoing) other features and new protocols.

Thomas

I just read Mike's blog post and I think he is putting the finger where it hurst, he's right on spot for every point, but one, and for that one PB is right, deviation shouldn't be forked the community will suffer from this and I fear that most likely both projects won't survive.

So the only real solution would be to make diversionTX the new deviationTX, rather than go reinvent the wheel elsewhere, just make it better here.

I agree that :

1.
We are past the "benevolent dictator" type of development in this project, others should, in particular the core developers team, be allowed to edit and change things around on all project related stuff (maybe it is already the case for some things dunno).

2.
Standard GUI has to go, look at how many people use OpenTX, Er9x and all those firmware flavors, if people want it people will learn it, don't cripple development with things from "last century".

3.
Development for crippled transmitters should be froze to it's actual state, if things like standard GUI should stay.

4.
Access to and documentation editing should be made easier, I really dislike (and maybe others) having to navigate (and loosing time) the bitbucket wiki, and having to rely on reading commits and searching for new stuff in thread scattered around the forum,. This isn't going to help anyone, when it comes to know what has changed or when new stuff is added to the firmware.

5.
Nightly builds should be renamed to something less intimidating, so new people would adopt them, instead of using 4.0.1 that is far less stable than latest nightlies

6.
A soft "à la" OpentTX/Er9x companion would be a must, this would resolve point five immediately, the nighlies would be just the next firmware release like they do, and that doesn't bother anyone from the beginning of those projects.


I know all of Mike's proposed changes will mean a lot of work, I'm no programmer (so can't help) and have very limited time (my wife's health condition takes a lot of my time), but I would be more involved if things would be easier to find and edit ,especially on the documentation field.

Adding new stuff without people being aware of it existence, or not knowing how to use it, is worthless and lets it confined to an elite class of users/developers.

So am I for the fork? No!

Make it better? Definitely!

And again a big thank you, to all of those, who give their free time to this project!

As a new devo 7e user i'd like to throw in my two cents as well.
I agree with both PB and mwm. One thing i really find sad is the lack of proper documentation like you all have said before. It exists but is all over the place. Consolidating that will be good.
Secondly i believe we should drop as many things that are not necessary such as the standard mixer from the 7e. I feel a bit bad holding back the other devos BUT the 7e probably accounts for ~40% of deviationtx users or something like that
How's the new bootloader / 12k free memory thing going

First things, the three things I think the community - or at least developers - most desperately need.

1. A new release. The reason nightly builds are more stable than the old release is because we haven't made any major changes since trying to get a release together last year. Pretty much everything I'm looking at is liable to make things less stable. In the current state of the nightly/release system, that's not really acceptable.
2. Make the build logs for the nightly builds visible somewhere. Right now, if I push a change and don't see a build, I get no clues as to what failed.
3. Document the nightly build process. Even if I have the build, what I have to do to recreate the failure may not be clear.

As for documentation, I'm happy with the state of the manual. But that's more a reference manual. The issue is that users can't contribute tutorials or howto's or similar things in a way that they can be found from the web site. The current bitbucket wiki (PB's not the teams) has valuable thing on it and is editable by anyone with a bitbucket account, but the only thing that isn't many links away from the deviation site is the module installation guide. In theory, such stuff can be posted to the forum, but between thread drift, the poor search facility in this forum software (I see the same issues on other sites using it) and that they are only editable by the original poster, they're not really much better than a blog post.

I don't really want to abandon the 7E, but I also don't want to have to worry about keeping things fitting during the transition phase. I had two things planned that I think would make things fit, but the first change would almost certainly break the 7E build, and those wouldn't happen until later.

Providing a desktop editor for configuration and making the config files on the transmitter binary would shrink the binary. IIUC, PB has already done some work on a desktop tool to convert the existing config files to/from binary just to save space on the 7E. That isn't my reason - I want to rework the config system for a number of reasons, the desktop config tool is something that showed up in the survey, and this is a natural place to do that. The ability to do mobile/web based configuration is a target to aim for after that, and should be kept in mind when doing it, but not a driver for it - at least not yet.

Once there's desktop software that you're interacting with on a regular basis, then something like the OpenTx build system - which lets you pick a set of features and builds a binary for that - seems like a natural next step. That would mean we no longer have some "standard build" that we have to make fit on a 7E. We could add conditional features at will, and then end users could build and install the set they wanted with little more pain than they'd have in installing a downloaded version with the desktop software. Figuring out other things to make conditional would also be worthwhile - telemetry, for instance. There are things I suspect most 7E users don't need that could save us space, like MM support (already conditional) or even individual RF module support. The audio player code is already conditional in that branch. Eventually supporting end-user builds was one of the reasons I built those docker images. They run on windows, OSX and linux as is, and provide a complete build environment for everything currently distributed.

before going any farther you guys need to consider greatly that afaics the 7e is THE most popular deviated transmitter, drop it and you'll lose a lot of the user base :/

PhracturedBlue wrote: ...... I would lie to focus on convincing you that I'm right 1st If I can't convince you to abandon the fork idea (at least for the imminent future) than instead we should talk about the best process to go forward with it. This is the elephant in the room, and we need to resolve it before we can move forward. .........

Freudian slip? j/k, ....I know that you just missed the K key.

I'm sorry, I thought I had said what was driving the fork, but I think I managed to skip it and went on to discussing how.

Anyway, it's not a matter of convincing me that you're right, it's a matter of convincing me that I'm wrong in thinking that I could write better firmware for the 6/8/10 if I could quite worrying about the 7E. And that's the real reason for wanting a fork - I'm tired of watching builds faile because I outgrew the 7E, or because I upgraded my build system and forgot to roll back the arm toolchain for it, etc.

Just dropping it from the build is the easy way I chose, but certainly not the only one. If you're willing to talk about how we can get around the 7E (and presumably the F7 and F4 if that ever gets finished) limiting other builds, then I'll certainly see how that works out before forking. It's not like I want a fork just to fork - it's because I'd gotten to the point where I couldn't see another way forward. And for the record, I'd be happy to wait a few months for that to get set up so a release can be done with the current sources.

I get all those points, but if the point of deviation is to release it for the community then it's largest base is the 7e, lose them and that community shrinks drastically, will devs still want to spend time on it then?

playing devils advocate i personally I find the current functionality of the 7e is perfect, the only thing i'd like to continue to be fixed/added is bugs and new protocols, and while I do use the standard gui for some of my old flybarred heli's it wouldn't pain me if it was removed. but lets be clear why it's beimg removed, what code is it your trying to add? what functionality does it provide on the 7e? as if it's not needed for the 7e why not make it turn off at compile time. as I;ve seen lots of complaints 'this wont fit the 7e' 'the 7e is holding back development of the other tx's' but no mention of what it is they are trying to add, or indeed if it's even usable on the 7e?

Personally, I'm more willing to spend time on deviation if I don't have to worry about the 7E, not less. There are a number of things in progress that could save space for it, but someone needs to take them on and finish them. That that hasn't happened makes me think that the developers aren't likely to vanish due to this change. Personally, I've never quite understood wanting a popular tool rather than a better tool.

The other things I put up in the blog post - and a few I didn't - are things I find irritating or frustrating in the current project. But they don't affect what runs on my transmitter, so don't warrant a fork. I listed them because I was planning on addressing them and thought it was worthwhile getting peoples input. I'll start a series of threads for those. The first one - about github, bitbucket and fossil - has already shown up since there was a thread discussing those issues. And as a warning, I don't think a fork is the most controversial of them

PhracturedBlue wrote: ...
At the moment I don't see many developers who are excited about developing for it (remember that the community is really only ~5 developers, of which the majority spend most of their time developing protocols and (with all likelihood I'm putting words in their mouths) are less likely to care one way or the other as long as their code fits in the 4k allocation).
...

You're not courting new developers very well. Certainly not with this web site. Where in the FAQ or on the front page does it point developers to how to build the code? My god!

It's all such a tower of babble. I have things I'd like to try. But where do I find the information that tells me how to quickly set up the build environment? This is free software, but it doesn't quite act like it. I've built other packages from other projects and it was relatively quick and painless. Getting started with this one looks like it will take weeks.

I'm not much of a spelunker. I've been tempted to dive in many times. But the information is way too hard to find.

We need a better web site. One that amplifies user's inputs and provides copious tools for mining and organizing information. And we need to cater to potential hackers and developers. This site does not do that.

The latest products must be accessible and very easy to find.

We have wiki now, and as far as I understand you are free to edit it and to add these nice and clear instructions you're talking about. Also, did you build many cross-compiled packages for which you need to bring in completely foreign build system (and on Windows slightly hostile)? It's another objective complicating factor.

And it did not take weeks for me - coordinated effort for several hours and I built it myself. Now with Docker images it's going to be even easier to start (I did not use them myself yet).