Re: If you want me to quit I will quit

[Richard Purdie <rpurdie@rpsys.net>]

On Sat, 2008-04-26 at 13:30 -0700, Andrew Morton wrote:
> On Sat, 26 Apr 2008 12:18:34 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > So it's an important part of the process to try to do a good job, and not 
> > publicizing crap - but it's *equally* important to realize that crap 
> > happens, and that it's easily *more* distracting to try to clean it up 
> > after-the-fact than it is to just admit that it happened.
> > 
> 
> Often it takes quite a long time for problems to become apparent.  Across a
> month or two we end up with things like:
> 
> mm-have-zonelist-contains-structs-with-both-a-zone-pointer-and-zone_idx.patch
> mm-have-zonelist-contains-structs-with-both-a-zone-pointer-and-zone_idx-fix-memcg-ooms.patch
> mm-have-zonelist-contains-structs-with-both-a-zone-pointer-and-zone_idx-just-return-do_try_to_free_pages.patch
> mm-have-zonelist-contains-structs-with-both-a-zone-pointer-and-zone_idx-just-return-do_try_to_free_pages-do_try_to_free_pages-gfp_mask-redundant.patch
> 
> and
> 
> mm-filter-based-on-a-nodemask-as-well-as-a-gfp_mask.patch
> mm-filter-based-on-a-nodemask-as-well-as-a-gfp_mask-doc-fixes.patch
> mm-filter-based-on-a-nodemask-as-well-as-a-gfp_mask-make-dequeue_huge_page_vma-obey-mpol_bind-nodemask.patch
> mm-filter-based-on-a-nodemask-as-well-as-a-gfp_mask-make-dequeue_huge_page_vma-obey-mpol_bind-nodemask-rework.patch
> 
> that's two patches, each with three followon fixes.  Very common.
> 
> Fact is, this is the way in which developers want to work.  That is their
> workflow, and their tools should follow their workflow.  If a tool's
> behaviour prevents them from implementing their desired workflow, it isn't
> the workflow which should be changed ;)

Its worth realising that these fix patches contain useful information
too, e.g. they might be by different authors and its also interesting in
some senses to see what fixes were applied to the original patch, why
etc. since it is history and that is what the SCM effectively stores.

This is also happens on larger timescales, a commit goes into some tree,
some regression is found, some future commit fixes that regression,
sometimes over a kernel release or two or more.

My point is that this information can actually be useful and trying to
prune it all out the main tree for aesthetic reasons might not
necessarily be the right thing to do. I agree it can be distracting and
perhaps what we need are tools that can show or hide this kind of
information as an option.

Consider that -stable tree and that if commits were somehow marked as
regression fixes for previous commits, you could run some command and
get a list of regression fixes. I'm a realist and appreciate such output
would need careful manual/human consideration but it would have a real
world use.

On the other hand I agree that the patches in -mm often have stupid
typos etc which aren't interesting in the history but where do you draw
the line?

Cheers,

Richard