--- On Wed, 3/11/09, Devin Heitmueller <devin.heitmueller@xxxxxxxxx> wrote: > From: Devin Heitmueller <devin.heitmueller@xxxxxxxxx> > Subject: Re: [PULL] http://linuxtv.org/hg/~mkrufky/sms1xxx-gpio > To: "Uri Shkolnik" <urishk@xxxxxxxxx> > Cc: "Michael Krufky" <mkrufky@xxxxxxxxxxx>, "Mauro Carvalho Chehab" <mchehab@xxxxxxxxxxxxx>, linux-media@xxxxxxxxxxxxxxx > Date: Wednesday, March 11, 2009, 4:59 PM > Hello Uri, > > On Wed, Mar 11, 2009 at 10:19 AM, Uri Shkolnik <urishk@xxxxxxxxx> > wrote: > > Answered above > > > >> #5 - Your patches break bisection tests. I broke > them > >> down to avoid this issue, but you prevented the > merge. > >> > > > > I don't know what are "bisection tests", please > elaborate. > > I think this point above may be where the communication > breakdown is. > The Linux kernel development environment is a little > different than > traditional source control environments. Here is how > it works: > > No *individual* patch is permitted to cause regressions > with devices > that are currently supported in the kernel tree. This > means that if > you have a patch series of ten patches and during > development you > found out patch # 3 breaks some Hauppauge device, you > cannot just > provide the fix in patch # 8. You actually have to go > back and > provide a new version of patch # 3 which does not have the > regression. > > Within a patch series, *every* patch has to compile, work, > and not > introduce regressions. This is because of what is > called bisecting - > which is a debugging technique where kernel developers use > an > automated binary search to look for the source of > bugs. For example, > if you submit a patch that doesn't compile, and you provide > the fix in > the next patch, then bisection doesn't work because a > developer > (possibly that is doing development completely unrelated to > the v4l > project) cannot bisect with the first version since his > kernel tree > will not compile. > > I took a look at the patches, and some of them are *huge* > by kernel > standards. I see single patches that fix five or six > issues. These > need to be broken down into individual atomic patches, each > describing > in detail what the change does. This is what Michael > has been doing. > > It's a change in mindset in that you need to not just think > about the > end result (which I'm confident passes all your internal > tests), but > also each intermediate step along the way. > > Devin > > -- > Devin J. Heitmueller > http://www.devinheitmueller.com > AIM: devinheitmueller > -- > 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 > Hi Devin, Thanks for the detailed explanation. After reviewing the entire chain of patches (10221...10239) I find that the entire chain, and each patch separately, suppose to pass bisection tests, since every such patch passed at least full sanity test at the time it had been submitted. If necessary, I can re-check it again (even I'm quite sure that I'll get the same results), or simpler, if there is a test that runs automatically over http://patchwork.kernel.org/project/linux-media/list , it should submit some kind of report, no? how do I get that report? 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
