On Sun, Apr 04, 2010 at 09:05:14AM +0800, jing zhang wrote: > > Without the cool git, though I am learning how to take advantage of > it, I could not manage all the patches delivered. In fact, I dig the > patches with UltraEdit for modifying the C code, Cygwin for git and > diff -Npu, and virtual machine for compiling. My kid, 11 years old > boy, has to share the HP notebook with me playing games. How much testing are you doing before submitting patches, out of curiosity? > I resolve conflicts and dependencies between patches in the way that > they are carried out by independent guys, since I am told that git is > cool enough. But indeed I created so many hard work for you, sorry. Having independent patches is actually better --- but I think you're misunderstanding what I was complaining about before. Patches should that are accepted into mainline should do one and only one thing. So if someone suggests that you make changes to your submitted patch, ideally what you should do is to resubmit the patch with the fixes --- and not submit a patch which is a delta to the previous one. This is especially true if the original patch is buggy; one of the things we try very hard to maintain is that the kernel tree compile cleanly, and pass the regression test suite, between every single commit. In other words, we try to avoid knowingly introducing a regression in a patch and fixing it in a subsequent patch. This allows things like "git bisect" to work, and it also makes it easier for people to look at the commit history to understand why certain changes were made, and especially when trying to find how a bug was introduced into ext4. Ultimately, this is about keeping the kernel source code easily maintainable. This means that incrased code complexity has to be justified, and code and code changes have to be meticulously documented. Best regards, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
