Re: [PATCH] pt3 (pci, tc90522, mxl301rf, qm1d1c0042): pt3_unregister_subdev(), pt3_unregister_subdev(), cleanups...

[AreMa Inc.]

Dear Antti, Mauro & others,

We don't want to flood the mailing lists with dirts.
It is regretful to send this kind of email, however
as we just received a "war declaration" from Tsukada Akihiro,
it is better to postpone delivering PT3 driver to the main kernel tree.

A series proof of facts follow.

Thanks again for your appreciation.
Bud @ AreMa Inc.

official contacts:
+81 50 5552 1666
info@xxxxxx


2014-10-04 16:16 GMT+09:00 AreMa Inc. <info@xxxxxx>:
> Hi Mauro,
>
> The biggest reason is that, the submitted driver, also published at
> https://github.com/knight-rider/ptx/tree/master/pt3_dvb
> is well proven to be running smoothly and already used by Japanese community
> for more than a year (i.e. de facto standard) without any major issues.
>
> The second is more about his personal reasons in violating the rules
> and we don't want to comment further unless there is no response from him
> within a week.
>
> Many patches will follow.
>
> Thanks again for your info.
> Regards
> -Bud
>
> 2014-10-03 19:52 GMT+09:00 Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxxxx>:
>> Em Fri, 03 Oct 2014 14:45:19 +0900
>> "AreMa Inc." <info@xxxxxx> escreveu:
>>
>>> Mauro & Antti
>>>
>>> Please drop & replace Tsukada's PT3 patches.
>>
>> It doesn't work like that. We don't simply drop a driver and replace by
>> some other one.
>>
>> The way most open source project works with regards to patch reviewing
>> process work is via lazy consensus. The maintainer could, of course,
>> override it, but this is only done on exceptional cases and when there
>> is a strong reason for doing that.
>>
>> The lazy consensus works like that: someone publish a patch at a public
>> mailing list. During a reasonable amount of time, everybody that
>> participates at the community can review the patch, and submit their
>> review publicly. After that time, it is assumed that everybody was happy
>> with the patch. The maintainers will then take it and merge.
>>
>> The PT3 patches are floating around for at least 2 merge windows, with is
>> a more than reasonable time. There were requests to change some bad things
>> there, to split the big patches into a series of patches, etc. All of them
>> were satisfied. So, as everybody lazily agreed with the code, it got merged.
>>
>> In other words, if you had anything against the merge of the PT3 driver,
>> you should have manifested before the merge during the ~2 months that this
>> was discussed, and not after that.
>>
>> Yet, if the driver is not fully functional or if it have some issues, we do
>> accept and we do want incremental patches fixing it. Of course, those changes
>> should be properly described. The patch descriptions should answer three
>> questions:
>>         - What each patch is doing;
>>         - Why that patch is needed;
>>         - How the change was done.
>>
>> As Antti stated, those incremental patches should be done with one logical
>> change per patch. That will allow us to better understand what's happening.
>>
>> In other words, you could, for example, send us a patch inside a series that
>> would be doing (from your previous patch):
>>         - lightweight & yet precise CNR calculus
>>
>> Such patch should look like:
>>
>> Subject: pt3: improve and cleanup CNR calculus
>> From: your real name <your@email>
>>
>> The current code uses a too complex logic to do CNR calculus.
>> Simplify the logic by doing ....
>> That keeps the CNR calculus precise, but makes the calculus
>> (quicker|easier to read|...).
>>
>> Signed-off-by: your real name <your@email>
>>
>> Please read what's written on our Wiki for more details, at:
>>         http://linuxtv.org/wiki/index.php/Developer_Section
>> Starting with:
>>         http://linuxtv.org/wiki/index.php/Development:_Submitting_Patches
>>
>>> There are too many weird & violating codes in it.
>>
>> You need to provide us a way more detailed descriptions than just the
>> above statement, as the above example
>>
>> E. g.: What is weird and where? What's being violated and where? What
>> you're proposing to solve it?
>>
>> Regards,
>> Mauro
>>
>>>
>>> Thanks
>>> -Bud
>>>
>>>
>>> 2014-10-03 13:54 GMT+09:00 Antti Palosaari <crope@xxxxxx>:
>>> > On 10/02/2014 09:49 PM, ÐÑÐÐ ÐÐÐÐÐÑÐ, AreMa Inc wrote:
>>> >>
>>> >> DVB driver for Earthsoft PT3 PCIE ISDB-S/T receiver
>>> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> >>
>>> >> Status: stable
>>> >>
>>> >> Changes:
>>> >> - demod & tuners converted to I2C binding model
>>> >> - i586 & x86_64 clean compile
>>> >> - lightweight & yet precise CNR calculus
>>> >> - raw CNR (DVBv3)
>>> >> - DVBv5 CNR @ 0.0001 dB (ref: include/uapi/linux/dvb/frontend.h, not
>>> >> 1/1000 dB!)
>>> >> - removed (unused?) tuner's *_release()
>>> >> - demod/tuner binding: pt3_unregister_subdev(), pt3_unregister_subdev()
>>> >> - some cleanups
>>> >
>>> >
>>> > These drivers are already committed, like you have noticed. There is surely
>>> > a lot of issues that could be improved, but it cannot be done by big patch
>>> > which replaces everything. You need to just take one issue at the time,
>>> > fix/improve it, send patch to mailing list for review. One patch per one
>>> > logical change.
>>> >
>>> > regards
>>> > Antti
>>> >
>>> > --
>>> > http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/