Deviation 5.0 release requirements

Any instructions to get inside the TravisCI? I want to have a look ^.^

I just create an account in github, how may I start contributing? My account name is richardclli

Summary RLS testing / release candidates / short term suggestions: www.deviationtx.com/forum/6-general-disc...-outs?start=20#44216
Links three older "release candidate / next release" threads.
Has anything really changed since these threads?


For the archives and forum searching:
I added several DSMx questions about latest changes to the "DSM telemetry support thread":
www.deviationtx.com/forum/protocol-devel...port?start=400#46358


Flybar heli:
I am about to re-assemble my Blade 450 3D flybar heli with front elevator servo.
I may be able to test pending heli mixer code changes for MantisBT #624 and #637 and newer code re-engineering that breaks old model.ini mappings:
www.deviationtx.com/mantisbt/view.php?id=624
www.deviationtx.com/mantisbt/view.php?id=637

What is the current plan to test / code change "simple mixer GUI" and advanced mixer (Cyclic1<->Cyclic2) for CCPM120 (flybar)? 5.0.1/5.1 patch? I am fine with that of course.


Update 17/09/2016:
Yes, there are still in release 5.0.0 known heli issues - and also some new issues (not seen before) with the committed heli templates according to several posted threads after 5.0 release: www.deviationtx.com/forum/6-general-disc...eased?start=60#53953

Please close MantisBT #590 - see comment: www.deviationtx.com/mantisbt/view.php?id=590

PhracturedBlue wrote: It is no secret that I am completely out of the loop on the current Deviation status,

That sounds familiar.

I just got a brand new white Devo 10, because the dispay of the Devo 8 sucks in sunlight, tried to use it at the field last weekend for the first time (after tinkering for years...), it's finally time to replace my trusty wk2801. I wonder if I could make a second Devo 10 from the Devo 8 CPU board and the WK2801 display. wuselfuzz.de/images/wk2801vsdevo10.jpg

Is there still an irc channel for deviation somewhere?

Got it, thanks.

To the above summary "release testing / release candidates / short term suggestions": www.deviationtx.com/forum/6-general-disc...ments?start=20#46348

I added several DSMx questions about latest (or open) changes to the "DSM telemetry support thread":
www.deviationtx.com/forum/protocol-devel...port?start=400#46358

If there might be some multiple weeks/months delay on release 5.0:
Would you please additionally consider a "4.0.1 (final?) release download" question from a new user on this thread: www.deviationtx.com/forum/3-feedback-que...n-drvo10-v4-01#47240


I am moving the discussion from the thread (with the wrong title) here.
My apologies if some blocks might re-phrase what has been already pointed out in previous linked short-term summary suggestion threads.

RedSleds wrote:

Thomas.Heiss wrote: Please guys & PhracturedBlue, at least delete the (final) release 4.0.1 directory and files from the download section as discussed in previous threads.
You are already planning for 5.0 release...so what.

Well, in my opinion it should not be deleted, but once v5.0 is officially released, it should then be moved to the "Older Releases" folder for legacy support reasons.

I would be of course fine with that too - if V4.0.1 release would be moved NOW to older releases directory
And maybe adding README/warning/releasenotes.txt to the zip with summary or link to the threads about the (severe) issues??

IMHO you guys really need to stop letting new users download V4.0.1 release - NOW.

....And then I see new users jumping on the forum and asking about old "V4.0.1 release" (to my understanding). Or was that in fact a question about latest nightly-build and not 4.0.1 (final) release??

How many V4.0.1 users may keep using <=4.0.1 and are not aware of those (severe) issues actually?


Sorry, I can't keep promoting DeviationTX on one hand on German forums, e.g RC-Network (updating transmitter thread regularly; where some guys already were keep kicking my butt about missing "declaration of conformity" / CE, 100mw FHSS limit in EU) when on the other hand a download "4.0.1 release" is even still offered (instead of just nightly-builds for now) with those known critical issues which have been discussed in threads and which are / might be fixed yet in nightly-build.

RedSleds wrote: Anyone that is new to DeviationTx should have done enough reading and research to know that v4.0.1 is ancient and the Nightly Builds are what they really need to be using.

IMHO this is just wrong.
Usually there are stable / well-tested release candidates and final releases.

If Spektrum publishes a new (alpha/beta or even well-tested and bug-fixed) firmware they will not even let you download old Airware firmware from SpektrumRC community (what I had seen so far).

Same stupid thing with former DX8 V2.04 firmware:
Spektrum KNEW for months (I guess this was almost 1 year) there is a mixer reboot bug and did not fix that for a longer time. I had to fly ~1 year with my DX8 with that bug.
Once they introduced a bugfix for that reboot issue it went into a full V2.05 release with critical complete subtrim (DX18) code changes (and of course with a new bug which had to be fixed in V2.06+ for reverse servo travel adjust additionally subtrim auto-update migration tool).
Why could they not bring first a hotfix just for the mixer thing?
But V2.04-V2.06 firmware did NOT contain any critical HF link issues like RF channel fix, CYRF reset, DSM protocol RX error checking fixes / improvements or "turn telemetry-OFF otherwise might link is lost and plane crashes" issue!


trunk/default is only the developer branch introducing new features.
Probably every (new) user expects it in THIS WAY without having to read weeks endless threads thru the forum.
As a user I would expect a well-tested and functioning release - with NOT known (severe) issues anymore.
As a new user I probably would never download the nightly-build first...

Bugfixes which are important have to follow a new release candidate and new stable release.
So usually important fixes would have to be back ported too - as we talked about earlier.

I already tried to explain this in the linked threads and tried to make a summary (see links above).


So many good improvement changes (e.g DSMx telemetry >255/0xFF) for FlightLog to appropriately use it without wrong 0xFF limit - which did not make it in any release candidate....

According to 2+ threads and linked "summary short-term suggestion list" the critical protocol bugfixes (which went into nightly-builds) have never made it into any release candidate nor have been back ported to V4.0.1/4.0.2++ and probably can not be anymore.

So the download warning in V4.0.1 directory does not IMHO reflect in any way the situation what is really going on behind the surface and what (critical) bug(s) seem to be still in V4.0.1 final release, which have already been fixed / improved only in the nightly-build.


I mean, come on...even my (critical) DSM protocol questions (latest 2015 changes or outstanding) published on the "DSM support thread" for nightly-build are open to be detail cleared...

RedSleds wrote: Besides, it is not that big of a deal to re-flash a Nightly Build when they figure it out at a later date.

Well, if they "figure it out" on 4.0.1 release - see (linked) threads about the sporadic issues - it might be too late because they might have already crashed their plane / heli.
Sorry, but I can not tolerate that the community just accepts crashes

Providing a release in the (active) download section - which is known that models might crash under some conditions (according to the many threads and summary) - is IMHO not a good thing. It is misleading.

Why can't we just live with only nightly-builds for now [until RLS 5.0.x] and prevent new users downloading the old 4.0.1 release?


Please please....change that concept if there might be some delay on 5.0 release.

Thomas

I can agree, with Thomas, bugs can happen but letting people download known "serious/critical" bugs is not good.

With regards DSM/DSMX, this is potentially dangerous, (although deviation software is at own risk), it is one of the few protocols were no modules needs to be installed. Also it is commonly used with bigger size models as people buy a spectrum Rx etc. It is not a typical micro quad china protocol, so people might expect from spectrum dsmx/dsm protocol to be reliable and might choose it.

Non toy protocols with potention for long range and bigger models; DSM/DSMX, FRSKY, Futaba FHSS, DEVO, FLYSKY
especially here dangerous situations to be avoided, if any open bugs here I think should be sorted.

user manual section 1, 1.1, 1.2 and 1.3 read it understand it, and make your choices www.deviationtx.com/user-manual/user-manual-7e-10

I edited my text above for a better meaning. You guys may have misinterpreted it? English is not my first language

Of course I am NOT talking about new/open firmware bugs (to be checked / fixed) but only the (critical) protocol issues in the linked threads above which are (or might be) fixed in nightly-builds.

@HappyHarry: Sorry, the disclaimer does not help any new user when the the old release directory - without the fixes - stays in the active download section

Thomas.Heiss wrote: @HappyHarry: Sorry, the disclaimer does not help any new user when the the old release directory - without the fixes - stays in the active download section

imo it does, the disclaimer and the aditional gnu gpl tells you that this software is provided as is, and may not work fully as intended. so installing and using it is entirely up to you, and it's your responsibility to test etc before using it. this is common in open source projects, and even the biggest open source projects have bugs.

plus in addition to the manual and the gnu gpl the front page of deviationtx.com also has this warning in bold text

WARNING: Deviation is experimental software. There are no guarantees made or implied about the quality or reliability of this software. RC models can cause serious injury or death if flown improperly. By deciding to use the Deviation software, you are taking sole responsibility for the control of your models. The authors of Deviation will not be held responsible for any injury or damage caused by the use of the Deviation firmware. Be cautious. You have been warned.