Re: linux-next: Tree for Oct 25

[Mark Brown]

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.

Attachment: signature.asc
Description: Digital signature