linux-kernel - Re: [PATCH 0/29] My patch queue for memorystick subsystem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 26 Oct 2010 04:32:13 +0200
From:	Maxim Levitsky <maximlevitsky@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Alex Dubov <oakad@...oo.com>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/29] My patch queue for memorystick subsystem

On Mon, 2010-10-25 at 09:07 -0700, Andrew Morton wrote:
> On Mon, 25 Oct 2010 07:39:58 -0700 (PDT) Alex Dubov <oakad@...oo.com> wrote:
> 
> > Normally, functional
> > patches should precede the cosmetic one, so that the functionality can be
> > discussed first.
> 
> More usually it's the other way around, actually: cleanups come first.
> 
> Because the cleanups are usually uncontroversial, and because
> substantive changes against cleaner code are easier to
> review/understand and because the substantive changes are then easier
> to revert or fix.

Exactly.

Now let me explain another technical reason why I did it that way.
First I created one big patch per driver I changed.
It really wasn't reviewable, but it was intended to review the end
result (the source file after patch was applied).
I did that because its really slows you down when you try to edit at
same time many patches. You have endless conflicts, you do lot of work
that you just remove in next patch etc.
Anyway this patchseries is a result of a lot of hard work (about month).

Alex pointer me that that isn't acceptable in linux community.
OK. I decided to bite the bullet and do that. It took me 2 full days to
split patches, test them (after all, I do honor the rule of
bisesctability).

Now why I put the cosmetic patches first?

Because that reduces conflicts during patch splitting dramaticly.

Consider this stack:

3: <top>
2: <few functions moved>
1: <few functions rewritten>
0: <existing source>

If I want to change patch #1, I will have to redo the patch #2 from the
start. That really sucks.

Now I could skip the functions that move code around, rename functions
etc to make Alex happy, but my goal was to minimize differences between
split-up series and original patch, so I could spare hard debugging.

This is result of lot of hard work.
I really want to see that in 2.6.37.

Best regards,
	Maxim Levitsky

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/