> > | I am very much in favor of keeping the tooling/framework/classes > | largely feature-frozen within a stable branch, and > selectively upgrade > | packages. > > That is my idea as well, I did backport the native.bbclass > change since it fixed rm_work, which is very important since > the backbone of our QA effort, the autobuilder, needs that. >
You got my vote on that. In general stable releases are "future frozen" and only security and other bugs get fixed i.e no new versions of packages unless they fix a bug etc Also taking into account the nature of OE a fishbone strategy would work better IMHO, as OE.dev tends to move fast and trying to keep up would be a big task i.e Three months prior to the stable release, sync with OE , "feature freeze" and backport bug fixes till stable is released. Then only security or critical changes get applied The proposed timeframe of 1 stable release per year looks good and will provide a good foundation for all distros based on OE Stelios S. Koroneos Digital OPSiS - Embedded Intelligence http://www.digital-opsis.com _______________________________________________ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
