On 23 January 2012 13:06, Gregoire Gentil <grego...@gentil.com> wrote:
> Hello, > > 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. > > - 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. > > 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. > > The point of my email was not to criticize the very interesting work of > Linaro but to give an external point of view. Let me know if Linaro has > already done some thoughts about this topic, and if such discussion can > occur formally or informally at the coming Connect event. > Thanks for the input Grégoire. I think "released" based software "engineering" is akin to manufacturing before the industrial revolution. Before the industrial revolution, skilled craftsman would work diligently to "release" a quilt, car, beer (still better hand-crafted), etc... As work was broken down into discrete steps and those steps were placed into an assembly line manufactures were able to hire many more less-skilled workers at a lower cost and were able to increase their industrial output by orders of magnitude. This brought the cost of "luxury" items down to a point where most everyone could afford them. Software is following the same trajectory. It used to be that software was one big monolith, developed by an extremely well skilled craftsperson. As we've built compilers, OS's, web-frameworks, etc... the skill level has gone down. This had led to an increase in the amount of software that can be developed and has brought the cost of software down so that everyone can enjoy it. The other thing that led to the mechanization of manufacturing was standardization. Back in olden days, people wrote proprietary code and sold that code. Many people wrote and sold code, and pushed divergent standards. When someone wanted to use one piece of code with another they had a hard time doing it because they were trying to integrate big things that we're meant to work together. With the opensource revolution, code was now relatively free and plentiful and generally worked well together because it had to, if your code didn't play well with others it wasn't really used. As opensource software has proliferated and has been further refined it has given developers and software manufactures a plentiful supply of standardized components that they can fit together easily. This has further pushed the mechanization of software engineering because the smaller standardized modules could be further refined by individual teams. As all of these modules come together into the software assembly line they are typically tested as a whole. The old way was to pull everything into a distribution discretely at different times, but its better if each submodule is delivered continuously. Then there's no delta between "release" and "testing." If you take this one step further, since we're building software you can actually build a version of "product" with just the single change, test it, and if it passes accept that piece of software into the mainline "product." This premerge testing allows all submodules to continue being developed against a good product and gates delivery of a new submodule on that submodule working with the product. This in turn allows all the software assembly lines to work most efficiently since there's no delta between their "release" and when that release has been "integrated and tested" with the whole, its done up front. Of course I didn't come up with any of this. This is how most Android products get developed. So for today's product builders, what they should do, is to tee off from a point in the Linaro Android CI loop into their own loops. They can then work towards their finished product in their own CI loop. If they're interested in updates of a particular component they can simply bring that component's assembly line into their assembly line and premerge test contributions. > > Best regards, > > Grégoire Gentil > Founder Always Innovating > http://www.alwaysinnovating.com > > > On Mon, 2012-01-23 at 18:28 +0100, Marcin Juszkiewicz wrote: > > Hi > > > > I am arriving on Saturday evening and wondered what to do on Sunday. > > Usually I spent time going to shops to buy some electronics but this > > time I think that will leave it for Amazon instead. > > > > That leaves me Sunday for sightseeing. According to Google Maps trip to > > Golden Gate bridge takes 2.5h by public transport or 40 minutes by car. > > But looks like there is no car rental in hotel ;( > > > > Is anyone interested in going for some tour? I think that San Francisco > > has some nice places to view. > > > > > _______________________________________________ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
_______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
