linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
To: "AreMa Inc." <info@are.ma>
Cc: linux-media <linux-media@vger.kernel.org>,
	linux-kernel@vger.kernel.org, Antti Palosaari <crope@iki.fi>,
	Mauro Carvalho Chehab <mchehab@osg.samsung.com>,
	Hans De Goede <hdegoede@redhat.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Michael Krufky <mkrufky@linuxtv.org>,
	Sylwester Nawrocki <sylvester.nawrocki@gmail.com>,
	Guennadi Liakhovetski <g.liakhovetski@gmx.de>,
	Peter Senna Tschudin <peter.senna@gmail.com>,
	knightrider@are.ma
Subject: Re: [PATCH 02/11] tc90522 is a client
Date: Sun, 5 Oct 2014 10:20:56 -0300	[thread overview]
Message-ID: <20141005102056.05861325@recife.lan> (raw)
In-Reply-To: <CAKnK8-REGVgdgQM+2KP0ibrf_gHMm_UO3oLr0MRoiu=-7vXUPw@mail.gmail.com>

Em Sun, 05 Oct 2014 21:39:01 +0900
"AreMa Inc." <info@are.ma> escreveu:

> Mauro,
> 
> As this _stable_ patch series is developed originally
> (and already submitted for review) since 2013,
> not based on Tsukada's patch you just linked,
> it is difficult to split into one patch per logic.
>
> As you said, for example, to fix the Tsukada's patch of tuner - FE - bridge
> communication, we need to fix all the files.

Yes, it requires lots of work, although it is possible. We've done that in
the past a few times, when such type of conflicts arise. 
It is always painful, though.

I did it myself some time ago, in order to add support for some newer
Siano hardware. The original patch submission were based on a diff between
the driver at the Kernel and some internal development tree used by
the chip manufacturer.

I waited for ~2 years for the original author to fix. As he didn't,
and I got some new hardware, I was forced to do the rebase myself.
It took maybe one week or two of hard work to get it done.

> We started developing and publishing PT3 drivers (chardev and DVB versions)
> on 2013 and have been submitting the patches to this community since then.
> We were waiting for reviews.

The reviews were sent, but it is really hard to review a big patch with
14 files changed and 2952 insertions that weren't following the Linux DVB
model, nor with the patches themselves were following the Kernel submission
process.

On every new review, a newer big blob were sent, sometimes repeating the
same pattern that the reviewers asked to change.

The entire review work is made by volunteers that have something else
to do. So, if you want a quicker review, you need to make their lives
easier, by splitting the drivers into smaller pieces and applying the
changes they request (or technically arguing with them at the e-mail
thread). Failing to do that makes the entire process longer.

> However this July, a man named Tsukada, who has been annoying us since
> the beginning of development (we invited him to merge/join the project,
> in other words, opted him to be co-author), interrupted our submission
> and started
> speaking ill of us that we didn't want to split the driver and stopped
> the development, etc.

At least the public comments I saw, I didn't notice anything ill about
you.

Splitting the drivers into frontend, demod and bridge driver is indeed
a requirement for DVB drivers submission. We do that even on devices
like as as102, where they're all integrated at the same chip, as such
split makes review a way easier, and decouples different logic functions
into different modules.

> This is not true. What we meant was that, it is too early to implement
> Regmap I2C
> for now (except if it is a firm consensus, surely we will do).

Regmap I2C is an improvement, but not a mandatory requirement.

> Unfortunately, you trusted him and put on the tree. If "backstabbing"
> is permitted,
> this will be a very bad precedence in our community.
> 
> We can send per logic patches without breaking the compilation,
> but we cannot guarantee the behaviour if you apply only one patch or two.
> Thus, pulling the clean package from
> 
>        https://github.com/knight-rider/ptx/tree/master/pt3_dvb
> 
> is the best bet. Or, do you have the card with you?

No, I don't have such card, nor I have any personal preference from
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.

Thanks and Regards,
Mauro

  reply	other threads:[~2014-10-05 13:21 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-05  8:59 [PATCH 00/11] pt3: pci, tc90522, mxl301rf, qm1d1c0042 Буди Романто, AreMa Inc
2014-10-05  8:59 ` [PATCH 01/11] tc90522: better chip description Буди Романто, AreMa Inc
2014-10-05 11:20   ` Mauro Carvalho Chehab
2014-10-05  8:59 ` [PATCH 02/11] tc90522 is a client Буди Романто, AreMa Inc
2014-10-05 11:33   ` Mauro Carvalho Chehab
2014-10-05 12:39     ` AreMa Inc.
2014-10-05 13:20       ` Mauro Carvalho Chehab [this message]
2014-10-05 14:16         ` AreMa Inc.
2014-10-05 17:08       ` Akihiro TSUKADA
2014-10-05  8:59 ` [PATCH 03/11] tc90522: use hardware algorithm & correct CNR Буди Романто, AreMa Inc
2014-10-05  8:59 ` [PATCH 04/11] pt3: add comment Буди Романто, AreMa Inc
2014-10-05  8:59 ` [PATCH 05/11] pt3: merge I2C & DMA handlers Буди Романто, AreMa Inc
2014-10-05  8:59 ` [PATCH 06/11] pt3: namespace cleanup Буди Романто, AreMa Inc
2014-10-05  8:59 ` [PATCH 07/11] mxl301rf: " Буди Романто, AreMa Inc
2014-10-05  8:59 ` [PATCH 08/11] qm1d1c0042: " Буди Романто, AreMa Inc
2014-10-05  8:59 ` [PATCH 09/11] mxl301rf: namespace cleanup & remodelling Буди Романто, AreMa Inc
2014-10-05  8:59 ` [PATCH 10/11] qm1d1c0042: " Буди Романто, AreMa Inc
2014-10-05  8:59 ` [PATCH 11/11] pt3: merge I2C & DMA handlers Буди Романто, AreMa Inc

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141005102056.05861325@recife.lan \
    --to=mchehab@osg.samsung.com \
    --cc=crope@iki.fi \
    --cc=g.liakhovetski@gmx.de \
    --cc=hdegoede@redhat.com \
    --cc=info@are.ma \
    --cc=knightrider@are.ma \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mkrufky@linuxtv.org \
    --cc=peter.senna@gmail.com \
    --cc=sylvester.nawrocki@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).