Re: [PATCH v3 1/7] rc: rc-ir-raw: Add scancode encoder callback

["David Härdeman" <david@hardeman.nu>]

On 2015-06-18 23:23, Mauro Carvalho Chehab wrote:
> Em Sun, 14 Jun 2015 01:44:54 +0200
> David Härdeman <david@hardeman.nu> 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