[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080426133049.187e255c.akpm@linux-foundation.org>
Date: Sat, 26 Apr 2008 13:30:49 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Stefan Richter <stefanr@...6.in-berlin.de>,
Adrian Bunk <bunk@...nel.org>,
Harvey Harrison <harvey.harrison@...il.com>,
Mauro Carvalho Chehab <mchehab@...radead.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: If you want me to quit I will quit
On Sat, 26 Apr 2008 12:18:34 -0700 (PDT) Linus Torvalds <torvalds@...ux-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 ;)
--
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/
Powered by blists - more mailing lists