linux-kernel - Re: [GIT]: Networking

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: <alpine.LFD.1.10.0808191348540.3324@nehalem.linux-foundation.org>
Date:	Tue, 19 Aug 2008 13:54:03 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Marcel Holtmann <marcel@...tmann.org>
cc:	David Miller <davem@...emloft.net>, akpm@...ux-foundation.org,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT]: Networking

On Tue, 19 Aug 2008, Marcel Holtmann wrote:
> 
> Also I cleaned up the MAINTAINERS file entries for Bluetooth. Are these
> considered harmful now and should be postponed to the next merge window?
> They can obviously not introduce any regressions?

What I consider harmful is not any individual commit per se, but the 
mindset that clearly says "hey, this particular commit is good, let's 
push it up".

And all of the commits are _individually_ fine and the likelihood for 
breakage is probably damn low, but when you have lots of them, that 
doesn't work any more. 

The whole point of the merge window is that you should be sending good, 
tested commits _then_. And if you miss the merge window, then you queue 
them up for the next one.

As it is, it seems like some people think that the merge window is when 
you send any random crap that hasn't even been tested, and then after the 
merge window you send the stuff that looks "obviously good".

How about raising your quality control a bit, so that I don't have to 
berate you? Send the _obviously good_ stuff during the merge window, and 
don't send the "random crap" AT ALL. And then, during the -rc series, you 
don't do any "obviously good" stuff at all, but you do the "absolutely 
required" stuff. 

The rule should be that if you have any doubt _what-so-ever_ that 
something is absolutely required, you simply don't send it during the -rc 
phase. And if you have any doubt at all about something not working, you 
don't send it during the merge window either!

The merge window is not for "let's get this tested, so that we can fix it 
during the -rc". And the stabilization phase is not for "this one looks 
obviously correct and safe".

		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/