linux-kernel - Re: [git pull] drm fixes

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]

Date:	Mon, 7 Jun 2010 13:52:37 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Dave Airlie <airlied@...il.com>
cc:	Dave Airlie <airlied@...ux.ie>, dri-devel@...ts.freedesktop.org,
	linux-kernel@...r.kernel.org
Subject: Re: [git pull] drm fixes

On Tue, 8 Jun 2010, Dave Airlie wrote:

> >         26 files changed, 372 insertions(+), 66 deletions(-)
> >
> > and there are apparently several reports of known problems (the problem
> > with modesetting) that isn't even addressed.
> 
> Okay, not sure what the addressed regression you are talking about, do
> you want  regression fixes early like you always say or do you want to
> wait until I have every regression reported fixes before I send a pull
> request?

I absolutely do want regression fixes early. If they've been verified to 
fix something, I do want to merge them as soon as possible.

But EVEN MORE IMPORTANTLY - and the point of me saying no - I do _not_ 
want non-regression fixes mixed in. Which clearly was the case here. So 
"as soon as possible" does not mean that I'll take _other_ things just to 
get the fix. The regression fix should stand on its own - and be merged 
on its own.

So no, it's not an excuse to send me a tree that contains other crud, and 
then use ".. but but you wanted regression fixes" as the excuse for 
sending those other changes too.

The whole point of the merge window is to then _after_ it closes no longer 
merge new code.

> I really hope you do this, if I find one thing going into your tree
> after today that isn't a regression fix I'll send revert patches if
> that'll help.

I don't like seeing revert patches unless they revert something that is 
buggy.  So no, "revert because I shouldn't have sent that commit" is not a 
good policy. If I end pulling something, it's my bad, and I won't revert 
it just because I made a mistake - it needs to be somehow actually be 
involved in some real problem.

But I _am_ trying to be proactive about problems during this particular 
release cycle. 

The point I'm trying to make is that I am going to be strict about the 
rules (the ones we've had for several years now, but people tend to be a 
bit loose about). I _should_ probably be stricter than I usually am even 
normally, but this time I am going to be very strict for -rc3 due to 
being away for part of the release cycle.

And no, don't worry - it's not just for you. I already rejected a 
microblaze pull for all the same reasons, and asked for some extended 
clarifications for a (much smaller) jffs2 pull despite the fact that we've 
generally not had lots of problems with jffs2.

		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/