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
