--- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
