Patch for /branches/frsky/src/main_views.cpp

[GoogleCodeExporter]

may I help with patch for issue81 in frsky?

Original issue reported on code.google.com by gbir...@gmail.com on 3 Jan 2012 at 9:06

Attachments:

• main_views.cpp.patch

[GoogleCodeExporter]

Original comment by gru...@gmail.com on 4 Jan 2012 at 12:44

[GoogleCodeExporter]

Thanks for the patch!

Actually I am not in favor of doing this port to the stable branch. If we do 
so, each time we take the risk of making it unstable (especially with me doing 
it).

What does Bryan think about it? 

Original comment by bson...@gmail.com on 4 Jan 2012 at 3:50

[GoogleCodeExporter]

I'm not following the main views code changes and thus this patch means little 
to me, without installing it, testing, etc. Nor have I been in any 
communication with others on the topic, whereas Bertrand has, which is why I 
assigned it to bsongis. I do agree that we shouldn't be changing the frsky 
release branch code for any reason other than bug fixes. Can this patch be 
considered a bug fix? If not, then it really has to remain in trunk.

Original comment by gru...@gmail.com on 5 Jan 2012 at 1:02

[GoogleCodeExporter]

OK I understood, for me no problem I use it in my own compilation of frsky.
What will be the expected implementation time of new features in frsky for 
users?

Original comment by gbir...@gmail.com on 5 Jan 2012 at 8:03

[GoogleCodeExporter]

Hang on though -- because it seems we're happy to include major changes to the 
way mixers work in the frsky version, despite what was recently said. So your 
patch may yet get included. (I am confused.)

Original comment by gru...@gmail.com on 5 Jan 2012 at 11:07

[GoogleCodeExporter]

A change in mixers algorithm? Not me.

Original comment by bson...@gmail.com on 6 Jan 2012 at 6:57

[GoogleCodeExporter]

OK ... I seem to have got that one VERY wrong. Apologies for the somewhat 
childish comment I made. Bertrand, I wish I could promise I'd never do it 
again! :-/ (I'm being quite serious, this time. Definitely, "my bad". Stress is 
the mother of all evil, I swear!)

Meanwhile, @bsongis -- this switch display thing is quite minor in the sense 
that it's not really a new feature. However, @gbirkus -- unfortunately, 
anything written to LCD display that goes even slightly wrong can actually 
bring down the whole radio. So it's a bit risky to port directly into the 
stable branch right now ... even though we can look at the code and just know 
that we know it's safe, as it were. More a case of policy, to save ourselves 
from ourselves, if you get my meaning.

It's a good enhancement and not what I'd call a "new feature" as such though. 
So perhaps we (meaning Bertrand! :-P) can establish a means of testing it 
"officially", in isolation and then port it to the stable branch? I'd be happy 
with that, on the basis that it's essentially just changes to existing display 
text ... pretty close. But it DOES need considered and proper testing, to be 
safe.

Original comment by gru...@gmail.com on 8 Jan 2012 at 10:45

• Changed state: Accepted

[GoogleCodeExporter]

I would say no. No port. If we go this way, all "good enhancements" in trunk 
will be ported to the stable branch (I am pretty sure there will always be a 
good reason for that). I am rather in favor of trying to shorten delays between 
two stable versions.

Original comment by bson...@gmail.com on 9 Jan 2012 at 9:05

[GoogleCodeExporter]

Agreed. This matches my comments in a recent private email, where I talked 
about "feature creep".

Original comment by gru...@gmail.com on 9 Jan 2012 at 11:56

[GoogleCodeExporter]

Then this issue may be closed :)

Original comment by bson...@gmail.com on 23 Feb 2012 at 1:44

• Changed state: Fixed