On Tue, 9 Nov 2010, Nicholas Mc Guire wrote: > On Tue, 09 Nov 2010, Tim Bird wrote: > > > On 11/09/2010 03:19 AM, Mike Frysinger wrote: > > > On Thu, Nov 4, 2010 at 18:07, Tim Bird wrote: > > >> It was noted at the summit that several CE companies and embedded > > >> projects will be using (or are already using) 2.6.35 for upcoming > > >> products or releases. This includes Sony, Google, Meego, and Linaro. On > > >> behalf of the CE Linux Forum and a number of consumer electronics > > >> companies, projects and community developers, we therefore declare > > >> 2.6.35 as a flag version of the kernel for embedded use. Several > > >> companies will be investing in development, integration and testing of > > >> this version. Entities wanting to do business with those companies would > > >> therefore be well-advised to make sure their hardware, drivers and > > >> enhancements work well with this version of the kernel. > > > > > > wouldnt it make more sense to piggy back the extensive work going into > > > the "stable" tree ? many of the points you raise after all are the > > > entire founding point of it. plus, all the main distros form around > > > that, are spending time working on that, is marked as supported for 2 > > > or 3 years, and there is already infrastructure/framework/process in > > > place (stable@xxxxxxxxxx). > > > > > > so instead of picking arbitrary versions (like 2.6.35) and needlessly > > > replicating the huge work load, simply declare these stable trees as > > > the "flag" versions. that means today it'd be 2.6.32.y. > > > > The fact that this tree is already a year old, and not likely to be > > brought forward for at least another 2 years is the reason we didn't > > choose it this time. Most of the high-profile, active embedded projects > > are already on 2.6.35. For companies looking to adopt a new base kernel > > in the next 12 months, I don't want to have them start with a year-old > > kernel. We did consider the utility of synchronizing with the enterprise > > stable tree, but the timing just didn't work too well this time around. > > > I guess one of the key issues is that it would need to be defined beforehand > what version will be used as the next "flag" version so vendors could make > sure that there drivers are available. Further if such a selection were to > be made then there would need to be consesus on maintaining the respective > version for a sufficiently long time to allow for the next "flag" version > to evolve. Finally for those working on products even if you would now define > the current version as the "flag" version it would not help much as they > would hardly be able to shift to a different kernel short term - so again the > key is defining what version would be atleast planed for the next "flag" > version - something like now defining it to be 2.6.38 - and then testing > appropriately in the runup to 2.6.38 to deliver, most notably for the > embedded architectures. FWIW, the imminent Linaro release is using 2.6.35. The next release scheduled for May 2011 will most probably use 2.6.38. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
