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

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@are.ma


2014-10-04 16:16 GMT+09:00 AreMa Inc. <info@are.ma>:
> 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@osg.samsung.com>:
>> Em Fri, 03 Oct 2014 14:45:19 +0900
>> "AreMa Inc." <info@are.ma> 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@iki.fi>:
>>> > 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/

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

[Mauro Carvalho Chehab]

Hi Bud,

Em Sun, 05 Oct 2014 18:36:54 +0900
"AreMa Inc." <info@are.ma> escreveu:

> 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@are.ma
> 
> 
> 2014-10-04 16:16 GMT+09:00 AreMa Inc. <info@are.ma>:
> > 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

Sorry, but the PT3 driver was already merged at the main tree and I can't
simply remove the PT3 patches without causing problems for all other patches
that are ready to be submitted.

What might be done would be to remove the driver on a separate patch,
but that would require a really strong reason for doing that.

At least from where I sit, tens of thousands kilimeters away from you both,
it sounds to me that we're talking about two different drivers for the
same piece of hardware. The big diff between your driver and his shows
that they're very different. 

That's the history of what happened with PT3 drivers submission:
	https://patchwork.linuxtv.org/project/linux-media/list/?submitter=6259&state=*
	https://patchwork.linuxtv.org/project/linux-media/list/?submitter=6368&state=*

All the public e-mails are there, and I don't care (not I am aware) of
any other e-mails exchanged in priv.

Both drivers had issues when submitted, and both series were properly
reviewed. Yet, Akihiro was fast to fix the pointed issues, and his patches
followed the proper submission rules since the beginning. Also, the 
per-driver patch split helped the reviewers to better do their work. 
His series was discussed during the last 3-4 months without a single reply 
arguing against its merge, and all comments pointing to issues at the driver
were fixed.

As it followed all the submission rules and fixup requests, it got merged.

So, I am unable to see any reason to remove his driver from the Kernel.

Am I missing something?

Regards,
Mauro

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

[AreMa Inc.]

Yeah, sorry if we are not familiar with submission rules as it was the
first time for us.
We already splitted the FE and tuners as I2C drivers, according to your request.

Maybe Tsukada is very clever and we are too busy with daily business,
but it doesn't mean that backstabbing is tolerated.
We already asked him to join the project, in a very good manner.

The fact is that, our DVB driver is already published and used widely
at least in Japan since August 2013
(chardev version is far earlier) and has become a de facto standard,
well tested without any major/minor issues
reported. Our driver is simpler/slimmer and yet, stable. And, it
conforms the rules of DVB core.

Or, do you have the card with you?

-Bud

2014-10-05 21:29 GMT+09:00 Mauro Carvalho Chehab <mchehab@osg.samsung.com>:
> Hi Bud,
>
> Em Sun, 05 Oct 2014 18:36:54 +0900
> "AreMa Inc." <info@are.ma> escreveu:
>
>> 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@are.ma
>>
>>
>> 2014-10-04 16:16 GMT+09:00 AreMa Inc. <info@are.ma>:
>> > 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
>
> Sorry, but the PT3 driver was already merged at the main tree and I can't
> simply remove the PT3 patches without causing problems for all other patches
> that are ready to be submitted.
>
> What might be done would be to remove the driver on a separate patch,
> but that would require a really strong reason for doing that.
>
> At least from where I sit, tens of thousands kilimeters away from you both,
> it sounds to me that we're talking about two different drivers for the
> same piece of hardware. The big diff between your driver and his shows
> that they're very different.
>
> That's the history of what happened with PT3 drivers submission:
>         https://patchwork.linuxtv.org/project/linux-media/list/?submitter=6259&state=*
>         https://patchwork.linuxtv.org/project/linux-media/list/?submitter=6368&state=*
>
> All the public e-mails are there, and I don't care (not I am aware) of
> any other e-mails exchanged in priv.
>
> Both drivers had issues when submitted, and both series were properly
> reviewed. Yet, Akihiro was fast to fix the pointed issues, and his patches
> followed the proper submission rules since the beginning. Also, the
> per-driver patch split helped the reviewers to better do their work.
> His series was discussed during the last 3-4 months without a single reply
> arguing against its merge, and all comments pointing to issues at the driver
> were fixed.
>
> As it followed all the submission rules and fixup requests, it got merged.
>
> So, I am unable to see any reason to remove his driver from the Kernel.
>
> Am I missing something?
>
> Regards,
> Mauro

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

[Mauro Carvalho Chehab]

Please don't do top-posting.

(moved your comments to the end of the email)

Em Sun, 05 Oct 2014 22:04:32 +0900
"AreMa Inc." <info@are.ma> escreveu:
> 
> 2014-10-05 21:29 GMT+09:00 Mauro Carvalho Chehab <mchehab@osg.samsung.com>:
> > Hi Bud,
> >
> > Em Sun, 05 Oct 2014 18:36:54 +0900
> > "AreMa Inc." <info@are.ma> escreveu:
> >
> >> 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@are.ma
> >>
> >>
> >> 2014-10-04 16:16 GMT+09:00 AreMa Inc. <info@are.ma>:
> >> > 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
> >
> > Sorry, but the PT3 driver was already merged at the main tree and I can't
> > simply remove the PT3 patches without causing problems for all other patches
> > that are ready to be submitted.
> >
> > What might be done would be to remove the driver on a separate patch,
> > but that would require a really strong reason for doing that.
> >
> > At least from where I sit, tens of thousands kilimeters away from you both,
> > it sounds to me that we're talking about two different drivers for the
> > same piece of hardware. The big diff between your driver and his shows
> > that they're very different.
> >
> > That's the history of what happened with PT3 drivers submission:
> >         https://patchwork.linuxtv.org/project/linux-media/list/?submitter=6259&state=*
> >         https://patchwork.linuxtv.org/project/linux-media/list/?submitter=6368&state=*
> >
> > All the public e-mails are there, and I don't care (not I am aware) of
> > any other e-mails exchanged in priv.
> >
> > Both drivers had issues when submitted, and both series were properly
> > reviewed. Yet, Akihiro was fast to fix the pointed issues, and his patches
> > followed the proper submission rules since the beginning. Also, the
> > per-driver patch split helped the reviewers to better do their work.
> > His series was discussed during the last 3-4 months without a single reply
> > arguing against its merge, and all comments pointing to issues at the driver
> > were fixed.
> >
> > As it followed all the submission rules and fixup requests, it got merged.
> >
> > So, I am unable to see any reason to remove his driver from the Kernel.
> >
> > Am I missing something?
>
> Yeah, sorry if we are not familiar with submission rules as it was the
> first time for us.
> We already splitted the FE and tuners as I2C drivers, according to your request.
> 
> Maybe Tsukada is very clever and we are too busy with daily business,
> but it doesn't mean that backstabbing is tolerated.
> We already asked him to join the project, in a very good manner.
> 
> The fact is that, our DVB driver is already published and used widely
> at least in Japan since August 2013
> (chardev version is far earlier) and has become a de facto standard,
> well tested without any major/minor issues
> reported. Our driver is simpler/slimmer and yet, stable. And, it
> conforms the rules of DVB core.

While looking on what happened in the past would help us to improve
future patch submissions, it won't solve the issues we're now facing,
as we cannot go back in time and fix it.

We need to move on, and the way for doing that is to submit incremental
patches improving the driver.

> Or, do you have the card with you?

As I wrote on another reply to this thread:

No, I don't have such card, nor I have any personal preference between
your version or Tsukada's one.

I might be ordering one and test here with my RF generators or ISDB-T
live, but very likely I won't have any time for coding, as my duties
as the maintainers require my attention on other things too. Also,
the problem here is not the lack of a developer for it, but, instead,
the lack of coordination between two developers.

So, I very much prefer if you could agree one with another around
a series of patches that would improve the driver without causing
regressions.

Regards,
Mauro