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:
pgptTOw9VtNaS.pgp
Description: PGP signature
