--- On Mon, 3/9/09, Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxx> wrote:
From: Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxx>
Subject: Re: [PULL] http://linuxtv.org/hg/~mkrufky/sms1xxx-gpio
To: "Michael Krufky" <mkrufky@xxxxxxxxxxx>, "Uri Shkolnik" <urishk@xxxxxxxxx>
Cc: linux-media@xxxxxxxxxxxxxxx
Date: Monday, March 9, 2009, 6:17 AM
On Sun, 08 Mar 2009 10:58:55 -0400
Michael Krufky <mkrufky@xxxxxxxxxxx>
wrote:
Uri Shkolnik wrote:
--- On Fri, 3/6/09, Michael Krufky <mkrufky@xxxxxxxxxxx>
wrote:
<snip/>
I reviewed your tree , which is indicated by the
email above, and compared it to a tree I built from the v4l
'trunk' repository + Siano's patches.
I found out two things -
1) The trees are still *very* differ from each
other
2) You applied *new* things that are _not_
included in the "old" Siano's patches (and some of them even
break it).
<snip/>
#1 The patches that you submitted break the currently
supported devices
#2 The patches that you submitted are not atomic
#3 The patches that you submitted introduce
regressions
#4 The patches that you submitted have multiple
changes in single patches.
#5 The patches that you submitted are not safe for a
git-bisection nor
hg-bisection
#6 The "codingstyle cleanups" that are intertwined in
your patches are
actually codingstyle regressions rather than
cleanups.
<snip/>
Uri and Michael,
We should try to do our best to avoid breaking the devices
currently supported
in kernel. That means that we shouldn't add a changeset
that we know that it
will break a device, except if we are committing, in the
same patch series,
another patch fixing it. This is probably the most
important reason why a patch
is not merged upstream.
Also, we should warrant that a patch won't break the
compilation of the kernel,
otherwise, the standard procedure to identify a broken
patch (bisect) will
fail. This affects not only our subsystem, but the entire
kernel, so this is
another important rule to be followed on patch submission.
That's said, I agree that we shouldn't commit the patch
series as-is. One of
you should rewrite the patch series to avoid breaking the
existing cards. On
the other hand, a patch shouldn't suffer large changes
without the
patch's author ack [1].
So, I ask you both to agree on some procedure, and to be
sure to not forward me
another patchset without both of you agree with it.
[1] yet, small changes like codingstyle adjustments and
merge conflict fixes
are ok, if properly documented with the proper meta-tag,
just before the SOB:
[my@xxxxxxxxx:
Codingstyle fixes and merge conflicts]
Signed-off-by: My name <my@xxxxxxxxx>
Cheers,
Mauro
Hi all,
Sorry for the delay in my replay, we had a holiday (always a good thing!), hope everything is OK with all of you.
Let me summaries the current status as I see it, and my suggestion for the near future.
There is big amount of changes and additions to the SMS based devices drivers pending since August 2008 (and even earlier), which should be merged into the hg (and the kernel git).
We have decided that Mike will take Siano's patches from the vger server, modify them if needed, and will merge them to the hg.
IMHO that we should alter our decision from the following reasons:
1) Mike is very busy (you may just give a short glimpse in the ML and see how many various patches he has introduced in the last week), that causes long delay (months) with the SMS drivers merge process.
2) At Siano QA department, the drivers are tested with big variety of different SMS-based devices using advanced automatic systems, with several DTV standards and sources. The drivers are also checked against various kernel versions (remember that the SMS drivers set is largely used with embedded-Linux devices, which are not always use the latest kernel, but they do upgrade their devices drivers), and all interfaces (SDIO, SPP, USB) are tested.
The drivers are also tested at various companies which either manufactures SMS-based devices, or use them (There is company that implements multimedia player that tests the recent drivers set with many devices, including Mike’s), and so on…
Mike can spend very limited time on testing, and he can test the drivers only on a single host-interface setup (x86/USB) and with very few devices (his company’s and Siano’s development modules).
My suggestion is that we’ll “reset” the process.
We know for sure (tested and verified) that the final result, after merging all Siano’s patches from the vger is robust driver set (which has also been tested with Mike’s devices). We also know it passes “checkpatch.pl” script (from kernel version 2.6.28) so it’s quite good, maybe some coding style issues still exist, but not too many.
So, the code itself is in good condition.
So, my suggestion is as follow –
Let’s take, one after the other, the patches from the vger server, and “put them on the surgeon’s table”.
Per *single* patch, one at a time, we’ll ask for anyone's review.
If there will be no comment, it will be committed as is. If there will be, I’ll fix it, pass it through the needed QA tests, and than it will be submit for a second review.
Hope to get your opinions about my suggestion soon,
Regards,
Uri
