Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1490379 > unrolled thread

Re: linux-next: Tree for Sep 21

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: linux-next: Tree for Sep 21 Linus Torvalds <torvalds@linux-foundation.org> - 2016-09-23 20:30 +0200
    Re: linux-next: Tree for Sep 21 Stephen Rothwell <sfr@canb.auug.org.au> - 2016-09-24 02:50 +0200
      Re: linux-next: Tree for Sep 21 Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-09-24 09:30 +0200

#1490379 — Re: linux-next: Tree for Sep 21

On Tue, Sep 20, 2016 at 11:08 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Changes since 20160920:
> [...]
> Non-merge commits (relative to Linus' tree): 11180
>  8424 files changed, 456474 insertions(+), 237951 deletions(-)

What happened here? The previous linux-next tree was much smaller. The
"changes since" part doesn't actually talk about the almost 3000 new
non-merge commits that very suddenly showed up.

I wonder if your automation could add some notes on things like this
when clearly one of the trees changes radically. Back in 20160920,
linux-next looked fairly small compared to previous releases. And then
the next day it suddenly looked quite big.

I get the feeling that several thousand new commits just before the
merge window opens is not a good sign. Of course, I'm planning an rc8
this time around anyway, but even so this is pretty surprising.

           Linus

[toc] | [next] | [standalone]

#1490517

Hi Linus,

On Fri, 23 Sep 2016 11:24:04 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> On Tue, Sep 20, 2016 at 11:08 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Changes since 20160920:
> > [...]
> > Non-merge commits (relative to Linus' tree): 11180
> >  8424 files changed, 456474 insertions(+), 237951 deletions(-)  
> 
> What happened here? The previous linux-next tree was much smaller. The
> "changes since" part doesn't actually talk about the almost 3000 new
> non-merge commits that very suddenly showed up.

That was Greg's (cc'd) greybus stuff entering the staging tree:

$ git rev-list --count --no-merges origin/master..2bbadafbe4ea
2363

> I wonder if your automation could add some notes on things like this
> when clearly one of the trees changes radically. Back in 20160920,
> linux-next looked fairly small compared to previous releases. And then
> the next day it suddenly looked quite big.

I will have a look at what can be done.  Normally trees do not grow in
large leaps, this was exceptional.  Most often such an increase would
be caused by one tree merging in another (both of which are often in
linux-next) e.g. the drm tree merges 8 other trees that I have and the
net-next tree also merges 8 others.

> I get the feeling that several thousand new commits just before the
> merge window opens is not a good sign. Of course, I'm planning an rc8
> this time around anyway, but even so this is pretty surprising.

-- 
Cheers,
Stephen Rothwell

[toc] | [prev] | [next] | [standalone]

#1490578

On Sat, Sep 24, 2016 at 10:42:45AM +1000, Stephen Rothwell wrote:
> Hi Linus,
> 
> On Fri, 23 Sep 2016 11:24:04 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >
> > On Tue, Sep 20, 2016 at 11:08 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > Changes since 20160920:
> > > [...]
> > > Non-merge commits (relative to Linus' tree): 11180
> > >  8424 files changed, 456474 insertions(+), 237951 deletions(-)  
> > 
> > What happened here? The previous linux-next tree was much smaller. The
> > "changes since" part doesn't actually talk about the almost 3000 new
> > non-merge commits that very suddenly showed up.
> 
> That was Greg's (cc'd) greybus stuff entering the staging tree:
> 
> $ git rev-list --count --no-merges origin/master..2bbadafbe4ea
> 2363

This is a staging driver (new hardware bus and drivers), self-contained,
and the development history of the code was preserved by importing it
this way.

The overall size of the kernel only grew by 35k of lines or so, not
much, but yes, the history did jump all at once.  Much like when we
imported btrfs the same way.

thanks,

greg k-h

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web