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

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

On Fri, 2014-05-23 at 10:11 -0400, John W. Linville wrote:
> On Thu, May 22, 2014 at 11:21:35PM -0700, James Bottomley wrote:
> > 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.
> 
> That's all well and good, but rebasing causes a lot of pain.

Not usually if you manage it right.

>   This is particularly true when you have downstream trees.

What I find is that people rarely actually need to base development on
my tree as upstream.  We do sometimes get the odd entangled patch (code
that changes something that changed in my tree), but we haven't had that
for a while now.  The rule therefore is use an upstream Linus tree to
develop unless you specifically have entangled patches.  If you need to
test with my tree, you can still pull it in as a merge.

I also have specific methodologies where I keep head and tail branches
of my trees, so for <x> development branch I have an <x>-base branch as
well, so I can simply do a

git checkout <x>
git rebase --onto origin/master <x>-base
git branch -f <x>-base origin/master

> In any case, bugs will eventually show-up -- probably on the day after
> you merge the 'final' series.  Hopefully those are not 'brown paper bag'
> bugs, but you can only stall a series so long in hopes of shaking
> those out.  You can only extend yourself so far in pursuit of bisectability.

Right, you have to have a "history commit" point ... for me that's when
I send the tree to Linus ... then the history becomes immutable and any
breakage discovered afterwards has to be fixed by separate patches.

James