All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.