Hey Rob, On Thu, Apr 5, 2012 at 11:10 PM, Clark, Rob <r...@ti.com> wrote: > just some random thoughts on our release model, etc.. I've been > meaning to write up for a while but haven't had time
Thanks for bringing this up here. > There has been some feedback, for example on #pandaboard, that the > monthly release cycle is confusing and detrimental for folks looking > for something working and stable, and not necessarily bleeding edge, > the question is, "should I upgrade?", "what is fixed and what is now > broken?". Linaro is doing some great upstream work, and enabling > features on these boards, and it is good to showcase that, but I'm not > really sure the best way to do this is rush that into the next monthly > release and break things for all the new users of their shiny new > xyz-board. > > I tend to think that part of the problem is that the cadence of > monthly releases is too fast for any sort of stability. Perhaps we > should think more along the lines of releases roughly every quarter > (potentially with "beta"s in between). I don't think we should > strictly adhere to a time based release cycle, but we should call it a > final/stable release when it actually is so. There is a reason that > the linux kernel uses an approx 3 month release cycle, but doesn't > stick to that dogmatically when things aren't really at release > quality yet. I think the main problem here is the constant change of direction from the platform group. Initially the Android/Ubuntu LEB (Linaro Evaluation Builds) were meant to be somehow stable, always delivering the best working components, even if they were not reflecting the latest upstream. On example of that is that we were still releasing the Pandaboard hwpacks based on the old tilt-linux-linaro-3.1, because it was the only one that was stable enough and had multimedia working out of the box. With this model, we attracted quite a few users, we presented our builds at numerous places (ELC, Connect, UDS, etc), got people at Linaro just to deal with community and always pointed the users to use them as reference, because it would always be somehow stable and working. Then at previous Connect Linaro decided that we would not worry about stabilising our LEBs any more, and start delivering just the latest components available, even if they would not be working with any other hw acceleration piece, which naturally made all of our users unhappy about it, getting us to the current situation. This is why I also thought we should go back and rethink how we would be dealing with our releases. The email I sent last week about stable/unstable LEBs is basically to cover the same issue. One thing we should do, if we're planning on working with *users*, is to always provide a working (stable) LEBs together with a unstable one, so if they decide to help and contribute to Linaro, they would always have the possibility to grab the latest stuff from the unstable PPA (on Ubuntu side). Now about the monthly releases I don't really have a strong opinion. I believe releasing the LEBs at every quarter might improve things, if we decided to get working (stable) LEBs out of the door. Doing it quarterly would give us have enough time to think about which components we'd be working on, and prepare the enablement properly (one thing we need to think about is that most of the builds require some sort of binary blob, and a one month-time frame is almost impossible for the Vendor to respin a newer version if needed). > But, we do still need a place for latest-and-greatest bleeding edge > for folks who want to check out what we are working on. One approach, > for example for ubuntu releases, we could have a "release" and "trunk" > PPA for bleeding-edge.. that way folks looking for bleeding-edge can > get it, and folks looking for "it just works" are not screwed. I'm > not quite sure what android equivalent would be, but I guess we could > figure something out. This gives folks in board specific channels > like #pandaboard who are trying to help new users something to > reliably point them at without having to worry if they are giving bad > advice to recommend a linaro filesystem. And updates do not have to > be tied to a time-based schedule. If something is broken for feature > x for board y in the release PPA, then as soon as it is fixed (and if > it doesn't break board z), then push an update to the release PPA. > But maybe big new features shouldn't immediately go to the release PPA > without some soak time first in the trunk PPA. It is great to be > enabling new features, but for someone new to the arm platform I don't > want to just frustrate and scare them off. This unstable/development place needs to be around, because that's also our main baseline when we're developing and testing our components. That's why for me the stable release would basically be a snapshot of a working unstable one, in a way we could later protect the users to avoid total breakage with a simple update. Cheers, -- Ricardo Salveti de Araujo _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
