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 gregoire@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-gene...
I hope that some of this information helps,