public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
	mingo@redhat.com, hpa@zytor.com, linux-kernel@vger.kernel.org,
	roland@redhat.com, suresh.b.siddha@intel.com, tglx@linutronix.de,
	hjl.tools@gmail.com, Andrew Morton <akpm@linux-foundation.org>,
	Linus <torvalds@linux-foundation.org>
Subject: Re: linux-next requirements
Date: Sun, 28 Feb 2010 08:51:05 +0100	[thread overview]
Message-ID: <20100228075105.GC14205@elte.hu> (raw)
In-Reply-To: <20100228183725.80915681.sfr@canb.auug.org.au>


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Ingo,
> 
> On Sun, 28 Feb 2010 08:14:05 +0100 Ingo Molnar <mingo@elte.hu> wrote:
> >
> > > [...]  As long as that's the case, linux-next should build on them too.
> > 
> > No, and IMO linux-next is clearly over-interpreting this bit. Linux is not 
> > supposed to build on all architectures. Maybe that's a core bit of a 
> > misunderstanding (on either my or on sfr's side) and it should be clarified 
> > ...
> 
> Well, we have no real problem then.  The only architectures for which a 
> failure will stop new stuff getting into linux-next are the ones I 
> personally build while constructing the tree (x86, ppc and sparc).  Once 
> something is in linux-next, even if it causes a build failure overnight, I 
> am loath to remove it again as it can cause pain for Andrew (who bases -mm 
> on linux-next).

Ok - very good. This has apparently been relaxed some time ago, i know 
linux-next used to be more stringent.

> I will still report such failures (if I have time to notice them - I mostly 
> hope that architecture maintainers will have a glance over the build results 
> themselves) and others do as well but such failures do not generally cause 
> any actions on my part (except in rare cases I may actually fix the problem 
> or put a provided fix patch in linux-next).

Yeah. Plus it's never black and white - sometimes a rare arch will show some 
real crappiness in a commit. So we want to know all bugs.

> I would like to add arm to the mix of the architectures I build during 
> construction, but there is no wide ranging config that builds for arm and 
> building a few of the configs would just end up taking too much time.

Yeah, ARM is clearly important from a usage share POV IMHO, and it's also 
actively driving many areas of interest.

It's also a bit difficult to keep ARM going because there's so many 
non-standardized hw variants of ARM, so i'm sure the ARM folks will appreciate 
us not breaking them ...

( Alas, ARM doesnt tend to be a big problem, at least as far as the facilities 
  i'm concerned about go: it has implemented most of the core kernel 
  infrastructures so there's few if any 'self inflicted' breakages that i can 
  remember. )

> Thanks for clarifying.

Thanks,

	Ingo

  reply	other threads:[~2010-02-28  7:51 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-11 19:50 [patch v3 0/2] updated ptrace/core-dump patches for supporting xstate - v3 Suresh Siddha
2010-02-11 19:50 ` [patch v3 1/2] x86, ptrace: regset extensions to support xstate Suresh Siddha
2010-02-11 23:18   ` [tip:x86/ptrace] " tip-bot for Suresh Siddha
2010-02-12  3:45   ` [patch v3 1/2] " Roland McGrath
2010-02-12 17:31   ` Oleg Nesterov
2010-02-11 19:51 ` [patch v3 2/2] ptrace: Add support for generic PTRACE_GETREGSET/PTRACE_SETREGSET Suresh Siddha
2010-02-11 23:19   ` [tip:x86/ptrace] " tip-bot for Suresh Siddha
2010-02-22  9:07     ` Ingo Molnar
2010-02-22  9:33       ` linux-next requiements (Was: Re: [tip:x86/ptrace] ptrace: Add support for generic PTRACE_GETREGSET/PTRACE_SETREGSET) Stephen Rothwell
2010-02-22 10:27         ` Ingo Molnar
2010-02-22 11:47           ` linux-next requirements " Stephen Rothwell
2010-02-22 22:57             ` H. Peter Anvin
2010-02-22 23:59               ` Stephen Rothwell
2010-02-23 20:20                 ` Roland McGrath
2010-02-23 20:49                   ` H. Peter Anvin
2010-02-23 22:54                     ` Stephen Rothwell
2010-02-23  8:45             ` Ingo Molnar
2010-02-23 19:52               ` Al Viro
2010-02-23 19:57                 ` Al Viro
2010-02-24  7:25               ` linux-next requirements Stephen Rothwell
2010-02-27  1:53                 ` Grant Likely
2010-02-27  8:53                   ` Geert Uytterhoeven
2010-02-27  9:09                 ` Jaswinder Singh Rajput
2010-02-27  9:39                 ` Ingo Molnar
2010-02-27 12:23                   ` Rafael J. Wysocki
2010-02-27 12:47                     ` Ingo Molnar
2010-02-27 19:07                       ` Rafael J. Wysocki
2010-02-27 21:50                         ` Geert Uytterhoeven
2010-02-27 22:31                           ` Rafael J. Wysocki
2010-02-28  7:06                         ` Ingo Molnar
2010-02-28 12:22                           ` Rafael J. Wysocki
2010-02-28  7:14                         ` Ingo Molnar
2010-02-28  7:37                           ` Stephen Rothwell
2010-02-28  7:51                             ` Ingo Molnar [this message]
2010-02-28  8:19                               ` Al Viro
2010-02-28  8:53                                 ` Ingo Molnar
2010-02-28 10:26                                 ` Stephen Rothwell
2010-02-28  7:23                         ` Ingo Molnar
2010-03-01 15:13                           ` Nick Bowler
2010-03-03 21:53                           ` Pavel Machek
2010-03-04  0:35                             ` Thomas Gleixner
2010-03-04  0:42                               ` Andrew Morton
2010-03-04  1:17                                 ` Thomas Gleixner
2010-03-04  2:48                                   ` Ingo Molnar
2010-02-22 18:37       ` [tip:x86/ptrace] ptrace: Add support for generic PTRACE_GETREGSET/PTRACE_SETREGSET Roland McGrath
2010-02-23 18:36         ` [tip:x86/ptrace] parisc: Disable CONFIG_HAVE_ARCH_TRACEHOOK tip-bot for Roland McGrath
2010-02-12  3:56   ` [patch v3 2/2] ptrace: Add support for generic PTRACE_GETREGSET/PTRACE_SETREGSET Roland McGrath
2010-02-12 15:59     ` Oleg Nesterov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100228075105.GC14205@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=hjl.tools@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rjw@sisk.pl \
    --cc=roland@redhat.com \
    --cc=sfr@canb.auug.org.au \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox