[git pull] drm fixes

[Linus Torvalds]

On Fri, Nov 19, 2010 at 12:24 PM, Dave Airlie <airlied at gmail.com> wrote:
>
> I also wonder if its partly psychological on your part, if I sent a
> number of smaller pull requests rather than queuing up things would
> you notice the line count less? If Chris sends things direct to you
> instead of me merging them and sending do you see a combined drm line
> count or do you just notice on a pull by pull basis etc.

Yes. I _love_ getting lots of separate pull requests if the subsystem
is big and the line counts start to grow.

But that only works if the separate pull requests are clearly separate
development threads. So it's not a matter of "send the pull requests
more often just make them smaller", but rather a matter of "send five
pull requests of different topic branches that are clearly separate".

I used to rave and rant at Ingo's x86 -tip tree, because I got huge
pull requests that were unmanageable. These days I don't, because I
instead get about thirty pull requests of individual topic branches,
and they don't depend on each other (well, at least most of the time)
so I can pull them in pretty much any order, and I know they've been
individually tested and each do one set of clear improvements.

And for the last year or so, not only don't I need to rant at the x86
people, it's been one of the most pleasant trees to work with.

Btw, it did end up forcing Ingo and company to change how they worked.
And it wasn't an entirely smooth transition, and it took three or four
release cycles of unpleasantness before it really started working. But
I'm pretty sure that if you ask Ingo and Thomas, they'll tell you that
it improved their flow too - it wasn't just a "make Linus happy"
thing, it's actually working really well and helped development.

And part of that is that it does require a bit of care. The patches go
into individual branches, and that's obviously more work and
forethought than just having a single "drm" branch. But then the
_advantage_ is that when things go wrong, they also go wrong in just
one small branch.  And the x86 -tip people can ask people to test just
specific branches.

And yes, it makes me much less unhappy about large pulls. The
cumulative patch may still be big, but if I get it in clearly separate
chunks, it ends up looking much cleaner and organized, so I get much
less worried.

But notice: I tend to really love that all during the *merge window*.
Post-merge-window, I'd still prefer to get clearly separate pull
requests, but at that point I really do want them to be _small_. If
they're not small at that point, there's still something wrong.

> Like I know the goal here is to create the perfect kernel for hardware
> Linus owns, but I'd like to be able to fix bugs urgently on hardware
> users have that aren't so privileged, think of it as some sort of
> outreach program.

Well, the complaint is at least partly about how it seems to be rather
much more unstable than some other (bigger) subsystems during later
-rc stages.

For example, comparing drivers/net with drivers/gpu, we find that
drivers/net has had a _lot_ more changes in this release:

  [torvalds at i5 linux]$ git diff -M --stat v2.6.36.. drivers/net/ | tail -1
   838 files changed, 92549 insertions(+), 39111 deletions(-)
  [torvalds at i5 linux]$ git diff -M --stat v2.6.36.. drivers/gpu/ | tail -1
   221 files changed, 19388 insertions(+), 11154 deletions(-)

so we're talking about a 4x difference here. Yet, when looking at what
happened since the merge window closed, it looks very different:

  [torvalds at i5 linux]$ git diff -M --stat v2.6.37-rc1.. drivers/net/ | tail -1
   54 files changed, 455 insertions(+), 238 deletions(-)
  [torvalds at i5 linux]$ git diff -M --stat v2.6.37-rc1.. drivers/gpu | tail -1
   87 files changed, 1667 insertions(+), 799 deletions(-)

now drivers/gpu (that had only a quarter of the changes overall) is
almost exactly the other way around.

Now, I realize that network drivers are simpler, and I'm sure there
are always good reasons. But still. I just get the strong feeling that
drivers/gpu isn't as well controlled, and that it's not following the
merge window nearly as well. Maybe things got pushed to me that really
weren't ready to be merged? Or, quite likely, the drivers/gpu people
don't try to control themselves as much.

And btw, don't take that too personally. I complain and push back on
the maintainers, and I really expect and hope that maintainers push
back on the developers. If people aren't honoring the merge window as
well as they should, you should try to push back on them. Don't take
"fix a bug and cleanup" kind of things. See if people can give you
just the bug-fix, and separate out the cleanup for later for the next
merge window.

Now, we're not really late in the merge window yet, but I'd really
like to think of the late merge window as a "stable" thing. If the
patch is something you'd send to stable, it should clearly go into the
late merge window. But if you wouldn't tag it with "Cc:
stable at kernel.org" after a release, maybe it shouldn't be pushed to
me?

                Linus