linux-kernel - Re: [git pull] Fixes to 2.6.30rc2

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1240086216.11172.2954.camel@gaiman.anholt.net>
Date:	Sat, 18 Apr 2009 13:23:36 -0700
From:	Eric Anholt <eric@...olt.net>
To:	David Miller <davem@...emloft.net>
Cc:	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [git pull] Fixes to 2.6.30rc2

On Sat, 2009-04-18 at 01:59 -0700, David Miller wrote:
> From: Eric Anholt <eric@...olt.net>
> Date: Fri, 17 Apr 2009 13:49:59 -0700
> 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel drm-intel-next
> 
> Eric, any plans to ever push your work through David Airlie's DRM
> tree?  I've been watching this for a few weeks and I'm mystified why
> the Intel DRM drier stuff is so special that is always goes seperate.
> 
> It's seems foolish for David to manage the infrastructure and core DRM
> changes, as well as those for radeon and the other drivers other than
> Intel, which could potentially cause merge issues and conflicts with
> your driver changes.
> 
> Why not do Intel DRM driver development via his tree?  I just don't
> get it. :-/

Inside of the merge window, I am going through Dave again because he
requested it (though delays meant that I didn't get a major cleanup in
this merge window).  However, Dave is also quite busy, and not stealing
his time every few days to pull my tree for just forwarding bugfixes on
seems to be a win.

-- 
Eric Anholt
eric@...olt.net                         eric.anholt@...el.com



Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)