linux-kernel - Re: lpc18xx: undefined Kconfig option ARCH

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] [day] [month] [year] [list]

Message-ID: <CACRpkdbxfb5C+Mny_J+LXmHqAaYO_aPYzdVUJDyenRefVsaysA@mail.gmail.com>
Date:	Wed, 13 May 2015 10:44:06 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Valentin Rothberg <valentinrothberg@...il.com>
Cc:	Joachim Eastwood <manabian@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	Alexandre Courbot <gnurou@...il.com>,
	Paul Bolle <pebolle@...cali.nl>,
	hengelein Stefan <stefan.hengelein@....de>,
	Andreas Ruprecht <andreas.ruprecht@....de>
Subject: Re: lpc18xx: undefined Kconfig option ARCH_LPC18XX

On Tue, May 12, 2015 at 4:57 PM, Valentin Rothberg
<valentinrothberg@...il.com> wrote:
> [Me]:
>> The answer to whether a certain maintainer will dare to do so
>> or not is per individual preference. The crucial point is that
>> "time savings" trumps "nothing can ever go wrong".
>
> I understand your point completely.  However, I see some cases critical,
> especially when configuration conditional code is added that cannot be
> compiled since the Kconfig option is not added yet or due to some other
> reason.  In precise, I see a conflict in the golden rule of "don't break
> the build".  As the code cannot be compiled, nobody knows if it's broken
> or not.  I see such things happening nearly daily.

I would say it is based on individual trust. Some contributors do not
send me untested patch sets so I know I can apply one or two of them
in isolation and trust the end result to be good if they work like this.

Individual trust is at odds with process. Process is based on the
bureaucratic ambition to work predictably and impersonal, such as
works the planets, or the plants. But maintainers in practice, while
applying some process, eventually work by personal trust which
is more ephemeral.

Yours,
Linus Walleij
--
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/