Closed GoogleCodeExporter closed 9 years ago
Original comment by gru...@gmail.com
on 4 Jan 2012 at 12:44
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
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
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
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
A change in mixers algorithm? Not me.
Original comment by bson...@gmail.com
on 6 Jan 2012 at 6:57
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
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
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
Then this issue may be closed :)
Original comment by bson...@gmail.com
on 23 Feb 2012 at 1:44
Original issue reported on code.google.com by
gbir...@gmail.com
on 3 Jan 2012 at 9:06Attachments: