lkml.org 
[lkml]   [2013]   [Oct]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: linux-next: Tree for Oct 25
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
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2013-10-28 09:21    [W:0.076 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site