On Fri, Nov 19, 2010 at 2:02 AM, Chris Wilson chris@chris-wilson.co.uk wrote:

Note it also contains a couple of fluff fallout patches from the recent drm-fixes rebase. (I thought it would be wise to include any core drm changes in our testing before sending the request...)

F*%^ me, why does drm always have to be so messy?

You guys pull each others trees, and then rebase them. Yes, git is smart enough that it will merge it all fine, but dammit, now that multi-hundred-line Radeon commit exists twice in the tree. Do this:

git show --stat 16790569eddf fba4312e223f git show --stat 21e2eae4daae a41c73e04673

and cry.

And yeah, it's ugly. And if that patch introduces a regression (which is entirely possible, it's not like it's small and trivial and obviously correct) it will just make bisection harder, and add confusion. And it's totally pointless. It only adds pain. And it makes the history harder to read.

Why did the Intel drm tree merge a patch that had _nothing_ what-so-ever to do with Intel DRM? WHY?

And why did the drm tree rebase a tree that had obviously been public and pulled from? WHY? Why did you make it public before it was ready? And/or why was it so ugly that it needed to rebase it? Why do these things keep happening?

What's wrong with the whole drm crowd? Even if it isn't rebasing, why is drivers/gpu/drm always so very visible in the later -rc trees?

I'm asking "why", but what I really want you guys to do is to ask _yourself_ why. And ask "Why is that? What am I doing wrong that this keeps happening?"

Really. Spend some time pondering. What the hell just happened, and why did it happen, and how can you guys stop doing it?

Chris: stop pulling in random crap in your tree. Do _your_ development in your tree. Nothing else.

And Dave, I have no idea why those two commits were rebased. They seem identical in the tree that Chris had pulled. They have the same base commit. What was the point?

Linus

On Fri, Nov 19, 2010 at 12:24 PM, Dave Airlie airlied@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@i5 linux]$ git diff -M --stat v2.6.36.. drivers/net/ | tail -1 838 files changed, 92549 insertions(+), 39111 deletions(-) [torvalds@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@i5 linux]$ git diff -M --stat v2.6.37-rc1.. drivers/net/ | tail -1 54 files changed, 455 insertions(+), 238 deletions(-) [torvalds@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@kernel.org" after a release, maybe it shouldn't be pushed to me?

Linus