Re: [Ksummit-discuss] [CORE TOPIC] [nomination] Move Fast and Oops Things

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Thu, 2014-05-22 at 22:56 +0200, Geert Uytterhoeven wrote:
> On Thu, May 22, 2014 at 10:31 PM, Dan Carpenter
> <dan.carpenter@oracle.com> wrote:
> > On Thu, May 22, 2014 at 09:31:44AM -0700, Dan Williams wrote:
> >> I agree that something like this is prickly once it gets entangled
> >> with ABI concerns.  But, I disagree with the speed argument... unless
> >> you believe -staging has not increased the velocity of kernel
> >> development?
> >
> > Staging is good because it brings more developers, but in many cases it
> > is a slow down.  Merged codes has stricter rules where you have to write
> > reviewable patches.  If there is a bug early in a patch series then you
> > can't just fix it in a later patch, you need to redo the whole series.
> 
> In theory...
> 
> These days many fixes end up as separate commits in various subsystem
> trees, due to "no rebase" rules and other regulations.

No, pretty much in practise.  I've no qualms about dropping a patch
series if one of the git tree tests shows problems and, since I have a
mostly linear tree, that means a rebase.

  I also don't believe in "preserving" history which is simply bug fixes
that should have been in the series.  Sometimes, if the fix took a while
to track down, I might keep the separate patch for credit + learning,
but most of the time I'd fold it into a commit and annotate the commit.

James