2010/4/5, tytso@xxxxxxx <tytso@xxxxxxx>:
> On Sun, Apr 04, 2010 at 09:05:14AM +0800, jing zhang wrote:
>
> How much testing are you doing before submitting patches, out of
> curiosity?
Yes, Ted, it is curiosity that drives me to do hard works, including patch ext4.
I already told you that I am happy to patch ext4.
I also like to share/deliver my patches to the developers and
maintainers of ext4, simply because I find something not correct or
perfect in the version I got at kernel.org, and because I am not 100%
sure. And review is necessary, as described in Andi Kleen's "On
submitting kernel patches", which I read last night. And I got that on
cmdline,
git --stat --summary a/x.c b/x.c > x-01.diff
may get nice output, correct?
It is hard work for me, a newbie, though curious, to do perfect patch,
and I try my best to describe the patch in English, which is not my
native language but one of the most beautiful languages on earth.
What is behind my curiosity is the belief that I will be freed both by
Jesus in West and by Buddha in East, today or tomorrow, if I deliver
what I can to those who need.
And after operations on cmdline, I compile the modified, modprobe, dd,
and rmmod with virtual machine. It is not hard.
> Having independent patches is actually better --- but I think you're
> misunderstanding what I was complaining about before. Patches should
Whatever you complain, I try to be a good listener every time:)
GNU Linux is free, is MIT free?
And I am free to change, to be responsible for what I did, or maybe
freed by you.
> 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.
I think what is called ext4 will change, and more will be freed by the
change, since it is under your maintenance, at least currently, a
model of maintainer, especially of strict requirement and kind
patience to patches received.
Good weekend, and please review my new patches next week.
Thank you, Ted.
- zj
--
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
