Release frequency: a discussion for Linaro Connect Q1.12?
james.tunnicliffe at linaro.org
Tue Jan 24 10:47:56 UTC 2012
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
On 23 January 2012 19:06, Gregoire Gentil <gregoire at 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:
> 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:
As part of our release process we ask people to try out our builds, in
fact our latest call for testing just went out:
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:
I hope that some of this information helps,
More information about the linaro-dev