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
