publishing an intermediate release 3.1.0?

  • rbe2012
  • rbe2012's Avatar Topic Author
  • Offline
  • So much to do, so little time...
More
14 Oct 2013 07:15 - 22 Oct 2013 14:22 #14604 by rbe2012
EDIT: If you are interested in the actual preparing work for deviation 3.1.0 you can look in my repository at bitbucket here:
https://bitbucket.org/rbe2012/deviation-3.1
From time to time I update the dfu files in the download area so you don't have to create a complete build environment to help us testing (or if you are just curious).
Take a look at the open issues to see what still has to be done and at the commits to see what is already achieved.


_____________________________________________________

Original post:
There are questions from time to time if the deviation project has died. We all know that this is not the case, but the lasting absence of PhracturedBlue as the main programmer and above all decider leads to this estimation.
If PB remains invisible, can we publish an intermediate version like a 3.5.0 (half way to deviation 4)?
I personally am sure that the (still actual) nightly build has no real big issues from the point of stability. Many use them and no real problems are reported as far as I have seen.
We should discuss what would be necessary to do this and which code base will be taken. We could declare the actual nightly as a regular version (so discussion about the nightlies could stop at least) or use some other code.
I would offer mine ( deviation-rbe-bugfixing ), but somebody should also have a good base.
There are some issues left in the nightlies (PBs repo has a list of 49). Maybe some of them can be solved if we work hard but surely not all (but open issues were no problem in the past when releasing a new version...). Which issues must be handled before we could offer a new version with a clear conscience?
Another point: how to publish a new version? We can not change PBs repo and we probably can not change the method the nightlies are created and uploaded.

I feel a little bit disloyal and unfair to PB, but I think this step is necessary and virtually overdue. And I really want to see him back here and keeping to bring his knowledge to deviation as he has done for a long time.
As we all know deviation is mostly his baby and I do not want to take it away from him. So I think we should only make changes which we expect he would agree to.
Last edit: 22 Oct 2013 14:22 by rbe2012.
The topic has been locked.
More
14 Oct 2013 07:38 #14609 by vlad_vy
Replied by vlad_vy on topic publishing an intermediate release 3.1.0?

rbe2012 wrote: Another point: how to publish a new version? We can not change PBs repo and we probably can not change the method the nightlies are created and uploaded.


You (or someone) can publish new unofficial intermediate release at 'Builds' forum. But I think this way havn't the future.
The topic has been locked.
More
14 Oct 2013 08:37 #14611 by SeByDocKy
Replied by SeByDocKy on topic publishing an intermediate release 3.1.0?
It would be great if a new version supporting FBL100/V922 can be published officially ...
The topic has been locked.
More
14 Oct 2013 09:21 #14613 by FDR
To see clear, this is what I can do, and what I can't do:
- I don't have any access to PB's repo;
- I don't have FTP access to this site;
- so I can't effect the automatic nightly builds;
- but I have full site admin rights, so:
- I can post in the downloads section (however it won't match the repo state);
- I can edit any article, menu, forum, user, etc...
The topic has been locked.
More
14 Oct 2013 09:46 #14614 by richardclli
Replied by richardclli on topic publishing an intermediate release 3.1.0?
Well, after knowing that PB is very busy at this moment, I have downloaded and installed the latest nightly build in my Devo 8S. Just want to use the nightly build on my regular basis and see if there are any critical bugs. Seems the nightly build is more stable than the v3.0.0, and I have not encounter any reboots as in v3.0.0 when I copy and setup models.

I will continue to use the nightly build and see if it is stable anyway.
The topic has been locked.
  • rbe2012
  • rbe2012's Avatar Topic Author
  • Offline
  • So much to do, so little time...
More
14 Oct 2013 11:31 #14620 by rbe2012
Replied by rbe2012 on topic publishing an intermediate release 3.1.0?

FDR wrote: To see clear, this is what I can do, and what I can't do:
- I don't have any access to PB's repo;
- I don't have FTP access to this site;
- so I can't effect the automatic nightly builds;
- but I have full site admin rights, so:
- I can post in the downloads section (however it won't match the repo state);
- I can edit any article, menu, forum, user, etc...

This is good to know. So we could change the "Home" page, post links to new versions on the download page (they should not be hidden somewhere in the forum) and write new release notes.

One important thing to do: update the documentation!
Volunteers needed...
The topic has been locked.
More
14 Oct 2013 11:36 #14621 by FDR

rbe2012 wrote: This is good to know. So we could change the "Home" page, post links to new versions on the download page (they should not be hidden somewhere in the forum) and write new release notes.

Yes.
The topic has been locked.
More
14 Oct 2013 12:37 #14626 by FDR

rbe2012 wrote: One important thing to do: update the documentation!
Volunteers needed...

I would leave that for someone with better english... ;)
The topic has been locked.
More
14 Oct 2013 12:56 - 14 Oct 2013 12:58 #14628 by blackmoon
Replied by blackmoon on topic publishing an intermediate release 3.1.0?
Isn't a sticky on the builds sub-forum better ?

That type of release should only correct bugs, and maybe add latest protocol development... and 3.5 is a big step, maybe 3.1 ?

And maybe discuss the way to go with PB when he returns, should he be absent for a long period like now.
Last edit: 14 Oct 2013 12:58 by blackmoon.
The topic has been locked.
  • rbe2012
  • rbe2012's Avatar Topic Author
  • Offline
  • So much to do, so little time...
More
14 Oct 2013 14:11 #14631 by rbe2012
Replied by rbe2012 on topic publishing an intermediate release 3.1.0?

blackmoon wrote: Isn't a sticky on the builds sub-forum better ?

Good idea, but supplementary.

That type of release should only correct bugs...

It will be an update of 3.0.0, not of the nightlies. So the complete new GUI will be part of - a quite large step if you consider the changes in the firmware, the config files and the handling.
I have no preferences for the number - 3.1 seemed to me a little bit close and it should be far enough away from 4.0 so I proposed 3.5 as some sort of compromise...

And maybe discuss the way to go with PB when he returns, should he be absent for a long period like now.

Absolutely!
The topic has been locked.
More
14 Oct 2013 14:25 #14634 by RandMental
Replied by RandMental on topic publishing an intermediate release 3.1.0?
I agreed we need an next release and 3.5 works for me.

As part of the preparations we need to update the default model.ini file to support the new GUI features - perhaps update the main screen to add more bars - (Personally I add 2 more vertical bars linked to the 6 typical CP heli channels to do a quick pre-flight check of gyro gains and flight modes etc.)

The Devo12 users may also want a new main screen all together, making full use of their larger screen

Any suggestions?
The topic has been locked.
More
14 Oct 2013 14:38 - 14 Oct 2013 14:47 #14635 by FDR
I would delete all the gui sections from the models/default.ini, so the default layout (layout/default.ini) could be used...

EDIT: ...and from all the empty modelXX.ini files too, of course...
Last edit: 14 Oct 2013 14:47 by FDR.
The topic has been locked.
More
14 Oct 2013 14:55 #14637 by RandMental
Replied by RandMental on topic publishing an intermediate release 3.1.0?
Makes sense
The topic has been locked.
More
14 Oct 2013 14:57 - 14 Oct 2013 15:04 #14638 by WheresWaldo
Replied by WheresWaldo on topic publishing an intermediate release 3.1.0?
I would be more than happy to look at the documentation and help with a rewrite.

I already posted somewhere else about the layouts that are currently underutilized. I would love to see all the GUI stuff out of the models and just a pointer to the correct layout like is done with icons. This way a layout could be done that includes all the screen available in one file and the model files become universal.

I have already started to look at the layout files when I ran into the problem that empty.ini only cleared Devos with color screens.

One thing I would love to see, is that all elements are available in all GUIs. This is a not so subtle plea for rbe2012 to bring back bigbox to the Devo7/10, please, please, please. :)
Last edit: 14 Oct 2013 15:04 by WheresWaldo.
The topic has been locked.
More
14 Oct 2013 15:39 #14639 by vlad_vy
Replied by vlad_vy on topic publishing an intermediate release 3.1.0?

FDR wrote: I would delete all the gui sections from the models/default.ini, so the default layout (layout/default.ini) could be used...

EDIT: ...and from all the empty modelXX.ini files too, of course...


In Nightly Builds it's already done.
The topic has been locked.
More
15 Oct 2013 00:09 #14649 by Essen1
Replied by Essen1 on topic publishing an intermediate release 3.1.0?
Guys,

If you do an update and a better GUI don't forget us plane flyers... :)
The topic has been locked.
More
15 Oct 2013 00:31 #14650 by cmpang
Replied by cmpang on topic publishing an intermediate release 3.1.0?
As the proposed imtermediate release is not meant to be so "offical", may be it is a good opportunity to incorporate the "two switch" feature into the 7e

cmPang
The topic has been locked.
More
15 Oct 2013 04:25 - 15 Oct 2013 04:36 #14651 by vlad_vy
Replied by vlad_vy on topic publishing an intermediate release 3.1.0?
It wiil be nice addition, if not influence users without additional switches and it will be well documented.

Possible, we can have at tx.ini section [enhancements] with options to activate such nonstandard features.

RBE, can you add to your fork all valid open issues from PB, and all enhancements from other users (protocols and etc.)?
Last edit: 15 Oct 2013 04:36 by vlad_vy.
The topic has been locked.
  • rbe2012
  • rbe2012's Avatar Topic Author
  • Offline
  • So much to do, so little time...
More
15 Oct 2013 06:00 - 15 Oct 2013 06:05 #14652 by rbe2012
Replied by rbe2012 on topic publishing an intermediate release 3.1.0?

vlad_vy wrote: It wiil be nice addition, if not influence users without additional switches and it will be well documented.

Possible, we can have at tx.ini section [enhancements] with options to activate such nonstandard features.

I know it exists (and it is a quite popular mod) but I have no way to test it (no Devo7e here) so how can we make sure it does not influence those who didn't add switches?
Please point me to the right thread and the code and I will look at it.
Best would be to open an issue in my repo.
We (or only me via PM, don't remember well) have discussed that with PB. He was more than skeptical about such user-specific addons. His main argument was exchangeability of the model configs. It is hard enough to map the different switches between the different tx models - it will be worse if we allow individual switches.
If the 7e turns into a 10 only with adding some switches everything will be fine. But there are not enough switches to add with the method used (integrating them in the button matrix) so we virtually would invent a new tx model (considering the model files). The only way to keep this clear would be a fixed naming for those switches and a clear mapping when using such a model config in any other tx.

Another argument was that not every 7e will have the additional switches. How can we see if the switches are integrated if they are not active? There is no way to detect an open line inside the tx... So we have to store somewhere the information that this tx has the switches mod done. But where? In the tx.ini? Giving it to your buddy makes model configs possibly useless. Somewhere hidden? This can be only in the code - but we surely don't want two different deviation versions for 7e... The MCU offers a unique processor id and I managed to read it. This could be used to allow such an addon only get active when the id is stored in the tx.ini - giving the tx.ini to someone else will lead to ignoring of the addons. Something like:
[enhancements]
txid=56789acb
switchmod=1
vibratingmod=1
(I have integrated a vibration motor in my Devo8) Here could also be integrated the rf module mods (but it will do no harm if they are tried to use without having them built in... so they can also stay where they are).
But I am not sure if this number is really unique (or if I am reading the correct one). It is different between my 8 and 12 but a processor model id would fulfill that too... We should test this.
If it works we can also store individual calculation parameters for the power state (see isue #6 in my repo) without having to fear that the values will lead to a miscalculation if applied to a foreign tx by moving the tx.ini.

RBE, can you add to your fork all valid open issues from PB, and all enhancements from other users (protocols and etc.)?

I don't know how to do that (copying issues) other than manually. While cloning PBs repo I have not seen any option allowing to copy the issues. So this will be an annoying work...
I am not sure if I want to do this. I always believed when PB is back he pulls the 3.5.0-code into his main repo and we go on as usual. Copying all the issues will look like a replacement for PBs repo.

What do you mean with "valid issues"? Simply "open"?

About the user enhancements: I have no accurate overview about the enhancements done outside of the deviation tree. I know there are some protocol works like HiSky and Spektrum telemetry but I did not really follow the threads (again I have no way for testing nor using it so it was not of too much interest for me).
The best would be: clone my repo, add your enhancements and send me a pull request. This seems the easiest way for me to see how it integrates.

I have to tell all of you that I am really very far away from the brilliancy PhracturedBlue has shown while developing deviation. If this 3.5.0 will happen it has to be a common work of us.
Last edit: 15 Oct 2013 06:05 by rbe2012.
The topic has been locked.
More
15 Oct 2013 07:24 #14654 by FDR
I would use the tx.ini for storing the enhancements like the switch mod without any unique tx id.
The tx.ini is already tx specific. For example there are the stick and screen calibration values. People shouldn't share or exchange tx.ini's...

I agree, that the additional switches should have fixed names, however it is possible to add 2 two state switches or 1 three state switch, so we rather should list the valid switch states (like MIX0+MIX1+DR0+DR1 OR MIX0+MIX1+MIX2), and then assign them to the line they use...
Then when loading a model config, the conversion should look if there are additional switches defined, and and convert them accordingly. Sure it will be more complex, then without...
The topic has been locked.
Time to create page: 0.081 seconds
Powered by Kunena Forum