On Fri, 4 Jun 2010 08:53:47 +0900 KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote: > On Thu, 3 Jun 2010 16:10:30 -0700 > Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > > On Wed, 2 Jun 2010 22:54:03 +0900 (JST) > > KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxxxxxxx> wrote: > > > > > > Why? > > > > > > > > If it's because the patch is too big, I've explained a few times that > > > > functionally you can't break it apart into anything meaningful. I do not > > > > believe it is better to break functional changes into smaller patches that > > > > simply change function signatures to pass additional arguments that are > > > > unused in the first patch, for example. > > > > > > > > If it's because it adds /proc/pid/oom_score_adj in the same patch, that's > > > > allowed since otherwise it would be useless with the old heuristic. In > > > > other words, you cannot apply oom_score_adj's meaning to the bitshift in > > > > any sane way. > > > > > > > > I'll suggest what I have multiple times: the easiest way to review the > > > > functional change here is to merge the patch into your own tree and then > > > > review oom_badness(). I agree that the way the diff comes out it is a > > > > little difficult to read just from the patch form, so merging it and > > > > reviewing the actual heuristic function is the easiest way. > > > > > > I've already explained the reason. 1) all-of-rewrite patches are > > > always unacceptable. that's prevent our code maintainance. > > > > No, we'll sometime completely replace implementations. There's no hard > > rule apart from "whatever makes sense". If wholesale replacement makes > > sense as a patch-presentation method then we'll do that. > > > I agree. > > IMHO. > > But this series includes both of bug fixes and new features at random. > Then, a small bugfixes, which doens't require refactoring, seems to do that. > That's irritating guys (at least me) because it seems that he tries to sneak > his own new logic into bugfix and moreover, it makes backport to distro difficult. > I'd like to beg him separate them into 2 series as bugfix and something new. > Sure, bugfixes should come separately and first. For a number of reasons: - people (including the -stable maintainers) might want to backport them - we might end up not merging the larger, bugfix-including patches at all - the large bugfix-including patches might blow up and need reverting. If we do that, we accidentally revert bugfixes! Have we identified specifically which bugfixes should be separated out in this fashion? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>