linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
	Mark Brown <broonie@kernel.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Olof Johansson <olof@lixom.net>
Subject: Re: linux-next: Tree for Oct 25
Date: Mon, 28 Oct 2013 09:01:24 +0100	[thread overview]
Message-ID: <20131028080109.GE6629@ulmo.nvidia.com> (raw)
In-Reply-To: <526AF150.1030004@infradead.org>

[-- Attachment #1: Type: text/plain, Size: 2270 bytes --]

On Fri, Oct 25, 2013 at 03:31:44PM -0700, Randy Dunlap wrote:
> On 10/25/13 08:03, Thierry Reding wrote:
> > Hi all,
> > 
> > I've uploaded today's linux-next tree to the master branch of the
> > repository below:
> > 
> >         git://gitorious.org/thierryreding/linux-next.git
> > 
> > A next-20131025 tag is also provided for convenience.
> > 
> > One new trivial conflicts and a new build failure caused by an incorrect
> > use of the genpool allocator.
> > 
> > Upon a request from Olof Johansson I've only included fixes for build
> > breakage as a result of interactions between the various trees. But
> > since I've fixed many of the other build failures already, I've pushed
> > those to a separate tag (next-20131025-fixes). That builds fine on x86
> > 32-bit and 64-bit allmodconfigs as well as ARM and x86 default
> > configurations. Most of the PowerPC build errors have also been fixed.
> 
> That's unfortunate.  The fixes should be part of the tree IMO.

Cc'ing Olof and Stephen.

Perhaps something like the above scheme might be a good compromise. On
one hand, many people are using linux-next for their daily work, myself
included. That implies that if linux-next doesn't build, people either
use a previous one that does build (so we don't get as much testing of
new trees as we possibly could) or they fix the build errors themselves
which in turn may cause potentially many people to have to fix the same
issues. On the other hand, if patches to fix build issues are included
then people might just assume that there are no problems.

I know that linux-next is a ton of work already and I don't expect this
to be done by Stephen alone. Perhaps people could collaborate some more
and provide a separate tag with additional build fixes and make sure
they get merged into the appropriate subsystems.

With such a scheme next-YYYYMMDD could serve as a metric of how good or
broken the various trees are, while next-YYYYMMDD-fixes would be a base
that people could use for daily work, with a set of known build fixes.
Perhaps it could even contain fixes for non-build issues, such as boot
failures, if we can come up with those quickly enough to make sense in a
linux-next context.

Any thought?

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

  parent reply	other threads:[~2013-10-28  8:01 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-25 15:03 linux-next: Tree for Oct 25 Thierry Reding
2013-10-25 15:03 ` linux-next: manual merge of the block tree Thierry Reding
2013-10-25 19:46 ` linux-next: Tree for Oct 25 (powercap_sys.c) Randy Dunlap
2013-10-25 22:17   ` Srinivas Pandruvada
2013-10-25 22:30     ` Srinivas Pandruvada
2013-10-25 21:01 ` linux-next: Tree for Oct 25 Guenter Roeck
2013-10-25 21:12 ` linux-next: Tree for Oct 25 (of_gpio.h) Randy Dunlap
2013-10-25 22:31 ` linux-next: Tree for Oct 25 Randy Dunlap
2013-10-26 16:59   ` Mark Brown
2013-10-28  8:01   ` Thierry Reding [this message]
2013-10-28 16:53     ` Mark Brown
  -- strict thread matches above, loose matches on Subject: below --
2023-10-25  5:37 Stephen Rothwell
2022-10-25  4:20 Stephen Rothwell
2021-10-25  9:49 Stephen Rothwell
2021-10-25 22:11 ` Dmitry Osipenko
2021-10-26  1:28   ` Ming Lei
2021-10-26  8:40     ` Dmitry Osipenko
2021-10-27 11:42 ` Stephen Rothwell
2021-10-27 12:54   ` Greg Kroah-Hartman
2021-10-28  1:51   ` Xianting Tian
2021-10-28  4:51     ` Stephen Rothwell
2021-10-28  7:59       ` Xianting Tian
2021-10-28 12:48         ` Stephen Rothwell
2021-10-28 12:54           ` Xianting Tian
2019-10-25  5:45 Stephen Rothwell
2016-10-25  3:31 Stephen Rothwell
2016-10-26  1:09 ` Paul Gortmaker
2016-10-27  6:21   ` Daniel Vetter
2012-10-25  4:01 Stephen Rothwell
2011-10-25  9:36 Stephen Rothwell
2011-10-25  9:43 ` Stephen Rothwell
2011-10-25 10:42 ` Stephen Rothwell

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=20131028080109.GE6629@ulmo.nvidia.com \
    --to=thierry.reding@gmail.com \
    --cc=broonie@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=olof@lixom.net \
    --cc=rdunlap@infradead.org \
    --cc=sfr@canb.auug.org.au \
    /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;
as well as URLs for NNTP newsgroup(s).