Hi Grégoire, Thanks for the mail. I am just a grunt here but I hope I am not too far off the mark with my replies. No doubt any mistakes will be corrected!
On 23 January 2012 19:06, Gregoire Gentil <grego...@gentil.com> wrote: > I'm Grégoire Gentil, the founder of Always Innovating. I intend to > participate to Linaro Connect Q1.12 though I'm not part of this > organization. I follow the work of Linaro and I find it very interesting > for our OMAP-based products such as the HDMI Dongle: > http://www.alwaysinnovating.com. > > I don't know if it's the right forum or if such discussion has already > taken place, but there is one point that I would like to raise up: > release frequency. Linaro is currently on a one-month period, which is > very tight. To my mind, such small period presents two disadvantages, > long-term perspective and innovation: > > - if there is a new release every month, it's hard to know which release > is *very* stable and should be used by an external company which might > not have the same frenzy to update all the time. There recently was a thread about how monthly releases, hopefully it will be infomative: http://lists.linaro.org/pipermail/linaro-dev/2012-January/009625.html As part of our release process we ask people to try out our builds, in fact our latest call for testing just went out: http://lists.linaro.org/pipermail/linaro-dev/2012-January/009810.html We would welcome more eyes on our builds. > - Regarding innovation, Linaro might learn from the Ubuntu experience. > Mark Shuttleworth was a strong advocate of the strict Ubuntu short > release schedule and he admitted later that a too frequent period > prevents from innovating. When you are pressed by a schedule, it's hard > for the organization to step back and take the time to break-through on > a novel approach. If short releases prevent long term software engineering projects from happening, then that is a problem. We try and avoid this by having monthly releases where changes are only released when they are ready. Since we release monthly, this reduces the pressure to rush a feature for a particular release (probably reducing its quality) since another release will happen shortly after. > The point of my email is not to convince Linaro to change the current > situation but to bring an idea for a complementary approach at least for > the first point: > > for instance, let's imagine a Linaro "super-stable once sometimes" > release. Right now, people are desperately looking for a "good" ICS > image - read Pandaboard groups if you are not convinced -, and ICS won't > change that much during the year. Perhaps there will be a 4.1 but when > you are doing a commercial product, you don't need the latest of the > latest and you certainly don't want to change your build process every > month. If there was a "good" ICS release today, I think that it would be > a major blockbuster for a lot of companies following Linaro. I'm > mentioning the Android example because it's what people want today, but > tomorrow it might be Meego or whatever. I'm not saying to stick to > Google schedule, it's just an example of what is trendy today and would > deserve long-term stable bits. > > To go one step beyond in my thinking, I'm not advocating for a new > separate *strict* longer schedule. The idea might be more to have *A* > milestone release from time-to-time, after something major is out > (Android release, new ARM cortex), and Linaro decides that this next > monthly release should be a major one, very polished, very stable and > it's properly supported and advertised with clear wiki and updates for > security or critical problems. There is a discussion on our release process at the next connect: https://blueprints.launchpad.net/linaro-project-management/+spec/linaro-general-release-process-improvements-lcq4.11 I hope that some of this information helps, -- James Tunnicliffe _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
