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@xxxxxx> escreveu:
> 
> 2014-10-05 21:29 GMT+09:00 Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxxxx>:
> > Hi Bud,
> >
> > Em Sun, 05 Oct 2014 18:36:54 +0900
> > "AreMa Inc." <info@xxxxxx> 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@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
> >
> > 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
--
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/