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

[Maxim Levitsky <maximlevitsky@gmail.com>]

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@yahoo.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