netdev - Re: [PATCH 02/14] net/fec: release mem_region requested in probe in error path and remove

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: <20110213.131531.57465973.davem@davemloft.net>
Date:	Sun, 13 Feb 2011 13:15:31 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	u.kleine-koenig@...gutronix.de
Cc:	netdev@...r.kernel.org, shawn.guo@...escale.com,
	kernel@...gutronix.de
Subject: Re: [PATCH 02/14] net/fec: release mem_region requested in probe
 in error path and remove

From: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
Date: Sun, 13 Feb 2011 22:07:09 +0100

> Hi David,
> 
> On Fri, Feb 11, 2011 at 09:25:32PM -0800, David Miller wrote:
>> I can't pull from that tree because it is _NOT_ based upon net-next-2.6
>> and therefore brings in all kinds of commits not related to your work.
> Sorry, I'm not used to the customs on netdev.  I can rebase, but still I
> wonder about the reason you cannot pull for.  The only reason I can
> imagine is that you fear unrelated breakage when taking these patches
> that are already in Linus' tree.  But if it's that, wouldn't it be great
> the realize this breakage already now and not only during the next merge
> window?

My trees only merge in Linus's tree when absolutely necessary,
to resolve conflicts or similar.

We don't bring in unrelated changes into my tree, just for the
sake of doing so.

Otherwise Linus gets all of these ugly merge commits when he
pulls from me, which are entirely unnecessary.


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html