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 Mon, Oct 28, 2013 at 09:01:24AM +0100, Thierry Reding wrote:

> 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.

This is one of the things that the per merge build tests really help
with - they filter out the vast majority of errors by just not letting
updates into -next (which applies some backpressure to get thing fixed
in the original tree too).

> 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?

This seems really tough to do given the rate of change of -next -
there's about 24 hours to get fixes in there before you have to rebase
forwards again.
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2013-10-28 18:21    [W:0.062 / U:0.836 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site