On 2015-06-18 23:23, Mauro Carvalho Chehab wrote:
Em Sun, 14 Jun 2015 01:44:54 +0200
David Härdeman <david@xxxxxxxxxxx> escreveu:
If you've followed the development of rc-core during the last few
years
it should be pretty clear that Mauro has little to no long-term plan,
understanding of the current issues or willingness to fix them. I
wouldn't read too much into the fact that the code was merged.
You completely missed the point.
Of course...
Adding new drivers and new features
don't require much time to review, and don't require testing.
But a focus on adding new "features" (some of which further cement bad
API) is dangerous when the foundations still need work.
What you're trying to send as "fixes" is actually series of patches
that
change the behavior of the subsystem, with would cause regressions.
Some things can't be fixed without changing some behavior...assuming
you're not talking about the patches that add a rc-core chardev...that
is indeed a whole new direction and I can completely take onboard that
you'd like to see a better RFC discussion with a document describing the
interface, changes, rationale, etc....and I'd be happy to produce a
document like that when I have the time (I'm guessing the LinuxTV wiki
might be a good place).
I have a total of six patches in my queue that are not related to the
rc-core chardev:
One fixes a uevent bug and should be trivial
One converts rc-core to use an IDA, a cleanup which seems to fix a race
as well
One removes lirc as a "protocol" and is not an API change as you thought
One prepares the lmedm04 driver for the next two patches
The last two adds protocol info to the EVIOC[GS]KEYCODE_V2 ioctl
The last two patches need the most careful scrutiny, but they are an
attempt to finally fix a serious issue. I've already indicated that they
are not 100% backwards compatible, but the corner cases they won't catch
(can't catch) are pretty extreme. I'd be happy to discuss them further
if you'd like.
I have no plans to move on to the rc-core chardev discussion before the
above patches have been dealt with. I don't think it's a good use of
anyone's time.
Btw, a lot of the pull requests you've sent over the past years did
cause
regressions.
Yes, trying to change/fix parts of the foundation of the rc-core code
definitely carries a larger risk of regressions (especially when I don't
even have the hardware). That's not a good reason to not try though.
So, I can only review/apply them when I have a bunch of
spare time to test them. As I don't usually have a bunch of spare time,
nor we have a sub-maintainer for remote controllers that would have
time for such tests, they're delayed.
I think we're getting off-topic.
Mauro....wake up? I hope you're not planning to push the current code
upstream???
What's there are planned to be sent upstream. If you think that
something
is not mature enough to be applied, please send a patch reverting it,
with "[PATCH FIXES]" in the subject, clearly explaining why it should
be
reverted for me to analyze. Having Antti/James acks on that would help.
This thread should already provide you with all the information you need
why the patches should be reverted (including Antii saying the patches
should be reverted).
The current code includes hilarious "features" like producing different
results depending on module load order and makes sure we'll be stuck
with a bad API. Sending them upstream will look quite foolish...
Regards,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
