|| ||Linus Torvalds <torvalds-AT-linux-foundation.org>|
|| ||Marcel Holtmann <marcel-AT-holtmann.org>|
|| ||Re: [GIT]: Networking|
|| ||Tue, 19 Aug 2008 13:54:03 -0700 (PDT)|
|| ||David Miller <davem-AT-davemloft.net>, akpm-AT-linux-foundation.org,
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
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".
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
to post comments)