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:	Sat, 27 Feb 2010 13:47:10 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>, mingo@...hat.com,
	hpa@...or.com, linux-kernel@...r.kernel.org, roland@...hat.com,
	suresh.b.siddha@...el.com, tglx@...utronix.de, hjl.tools@...il.com,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus <torvalds@...ux-foundation.org>
Subject: Re: linux-next requirements


* Rafael J. Wysocki <rjw@...k.pl> wrote:

> > > Lets see.  Over the last 60 days, I have reported 37 build errors.  Of 
> > > these, 16 were reported against x86, 14 against ppc, 7 against other 
> > > archs.
> > 
> > So only 43% of them were even relevant on the platform that 95+% of the 
> > Linux testers use? Seems to support the points i made.
> 
> Well, I hope you don't mean that because the majority of bug reporters (vs 
> testers, the number of whom is unknown to me at least) use x86, we are free 
> to break the other architectures. ;-)

It means exactly that: just like we 'can' break compilation with gcc296, 
ancient versions of binutils, odd bootloaders, can break the boot via odd 
hardware, etc. When someone uses that architectures then the 'easy' bugfixes 
will actually flow in very quickly and without much fuss - and without 
burdening developers to consider cases they have no good ways to test. Why 
should rare architectures be more important than those other rare forms of 
Linux usage?

In fact those rare ways of building and booting the kernel i mentioned are 
probably used _more_ than half of the architectures that linux-next 
build-tests ...

So yes, of course _all_ bugs need fixing if there's enough capacity, but the 
process in general should be healthy, low-overhead and shouldnt concentrate on 
an irrelevant portion of Linux usage in such a prominent way.

Or, if it does, it should _first_ cover the other, much more burning areas of 
testing interest. All the while our _real_ bugreports are often rotting on 
bugzilla.kernel.org ...

Thanks,

	Ingo
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ