On 8 July 2011 12:50, john stultz <johns...@us.ibm.com> wrote: > On Fri, 2011-07-08 at 12:35 -0700, Deepak Saxena wrote: >> On 1 July 2011 12:14, Deepak Saxena <dsax...@linaro.org> wrote: >> > Each of the trees have various tags and branches based on how each >> > team and developer >> > works and I don't want to ask folks to change what they are doing for >> > their day to work. >> > What I'd like to see is a a separate set of official trees that only >> > get updated with bits that >> > we are ready for non-Linaro developers to use, do not get rebased, and >> > get tagged at the >> > end of each monthly cycle. My proposal: >> > >> > kernel/linux-linaro-$version with tags for each monthly release: >> > v$version-$milestone-$buildcount > > So tag wise, since its a source release, by build count you mean more > like "drop number" or something?
Yes, so if we release a tarball and two days later we update it due to a critical bug, we'd increase the buildcount. > So a concrete example would be: > > v2.6.39-11.06.4 > >> > kernel/linux-linaro-android-$version with tags for each monthly >> > release: android-v$version-$milestone-$buildcount > > android-v2.6.39-11.06.4 ? > > The catch here is there may be multiple android drops for one linaro > drop. > > So it would seem: > v2.6.39-11.06.4-android-2 > > Or v$version-$milestone-$buildcount-android-$androidbuildcount Yep, that makes sense. ~Deepak _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
