netdev - 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: <20080819222612.GA16766@2ka.mipt.ru>
Date:	Wed, 20 Aug 2008 02:26:12 +0400
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Linus Torvalds <torvalds@...ux-foundation.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, Aug 19, 2008 at 02:50:36PM -0700, Linus Torvalds (torvalds@...ux-foundation.org) wrote:
> And the thing is, you cannot. Some of the ones I pointed you to were 
> actually regressions due to _other_ patches you had much too happily sent 
> me after the merge window had already closed).

... phisiological thoughts skipped ...

> Please. You're still making excuses for this, even after I pointed out 
> that ALL of the problems with the whole loopback driver thing happened 
> after the merge window. 

I belive it was you who told that there is no black and white (another
guy told that there is no spoon, I frequntly confuse).

Any changes made no matter when can not be 100% tested in laboratory
environment, even fixes, which look obviously. Even changes which do fix
some problems can introduce another. And some fixes can introduce
problems, which are not immediately shown in majority of the tests, so
changes on top of them can look like introducing new bugs. If you have
multiple changes and result which produce an error, it does not mean
that the last one was wrong. Of course it can, but 'there is no black
and white', and in really complex system only trivial changes can be
thought of not touching others. The same applies to loopback. So this
particular note is just about the fact, that fixing regression means
either reverting a change or introducing a new change. The latter is
preferred (or at least should be), since it is a move forward.

According to other changes, which you believe are not suitable for the
post merge window releases... People do know that major changes are not
allowed to be made, but there are always last strikes in the head which
are supposed to fix problems, not to introduce new ones. Where did you
see experimental code in -rc cycle? Where did you see patches which
break things without bringing improvement at that time? Yes, there
changes which are not supposed to be in the tree at that time, but
that's just a development process, which even in a short run makes good
result. Regressions and bugs are fixed, and things are not getting worse
with time.

-- 
	Evgeniy Polyakov
--
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