lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTikiZRHKRrosXgY5TEYODN_D_JLJ0XXWSb9g1zPQ@mail.gmail.com>
Date:	Fri, 19 Nov 2010 11:04:37 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Chris Wilson <chris@...is-wilson.co.uk>
Cc:	Dave Airlie <airlied@...ux.ie>, linux-kernel@...r.kernel.org,
	DRI mailing list <dri-devel@...ts.freedesktop.org>
Subject: Re: [git pull] drm fixes

On Fri, Nov 19, 2010 at 2:02 AM, Chris Wilson <chris@...is-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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ