Hi all,
I was looking at git.linaro.org and I'd like to propose some consistency in naming our git trees and in how we branch them. The main reason for this from my perspective is to make it easy to point someone from a partner team or from a partner''s customer to the git server and have them quickly figure out what they need to pull. Right now we have:
Generic Linaro Kernels:
kernel/linux-linaro-${version}
Freescale:
bsp/freescale/linux-2.6-imx.git bsp/freescale/linux-linaro-natty.git bsp/freescale/linux-meta-linaro-natty.git bsp/freescale/mx5-gpu.git bsp/freescale/mx5-vpu.git bsp/freescale/u-boot-linaro-natty.git
Samsung:
bsp/samsung/linux-linaro-2.6.39.git bsp/samsung/u-boot-insignal-dev.git bsp/samsung/u-boot.git
ST-E: bsp/st-ericsson/firmware-ux500.git bsp/st-ericsson/linux-2.6.34-ux500.git bsp/st-ericsson/linux-2.6.35-ux500.git bsp/st-ericsson/linux-2.6.38-snowball.git bsp/st-ericsson/linux-2.6.38-ux500.git bsp/st-ericsson/u-boot-ux500.git
TI: people/andygreen/kernel-tilt.git
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 kernel/linux-linaro-android-$version with tags for each monthly release: android-v$version-$milestone-$buildcount kernel/$soc/linux-linaro-$version with tags for each monthly release: $bsp-v$version-$milestone-$buildcount kernel/$soc/linux-linaro-android-$version with tags for each monthly release: $bsp-android-v$version-$milestone-$buildcount
Comments?
~Deepak
On 07/01/2011 08:14 PM, Somebody in the thread at some point said:
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 kernel/linux-linaro-android-$version with tags for each monthly release: android-v$version-$milestone-$buildcount kernel/$soc/linux-linaro-$version with tags for each monthly release: $bsp-v$version-$milestone-$buildcount kernel/$soc/linux-linaro-android-$version with tags for each monthly release: $bsp-android-v$version-$milestone-$buildcount
Comments?
It would be less ridiculous than issuing monthly tarballs for the kernel case.
However if you follow this logic to its natural conclusion you end up with a text file listing git repos and tags, maybe build config filenames... that sounds better to me.
-Andy
On Fri, Jul 1, 2011 at 9:21 PM, Andy Green andy.green@linaro.org wrote:
It would be less ridiculous than issuing monthly tarballs for the kernel case.
why do you think that tarballs are ridiculous? even kernel.org releases tarballs last I looked. IMO you can prefectly have tags + tarballs coexist and everbody would be happy.
On 07/04/2011 10:25 AM, Somebody in the thread at some point said:
On Fri, Jul 1, 2011 at 9:21 PM, Andy Greenandy.green@linaro.org wrote:
It would be less ridiculous than issuing monthly tarballs for the kernel case.
why do you think that tarballs are ridiculous? even kernel.org releases tarballs last I looked. IMO you can prefectly have tags + tarballs coexist and everbody would be happy.
Because there are few or no people that want a fly frozen in amber for a kernel divorced from its patch history and context to add patches to.
-Andy
On Mon, Jul 4, 2011 at 11:31 AM, Andy Green andy.green@linaro.org wrote:
On 07/04/2011 10:25 AM, Somebody in the thread at some point said:
On Fri, Jul 1, 2011 at 9:21 PM, Andy Greenandy.green@linaro.org wrote:
It would be less ridiculous than issuing monthly tarballs for the kernel case.
why do you think that tarballs are ridiculous? even kernel.org releases tarballs last I looked. IMO you can prefectly have tags + tarballs coexist and everbody would be happy.
Because there are few or no people that want a fly frozen in amber for a kernel divorced from its patch history and context to add patches to.
https://launchpad.net/linux-linaro/2.6.39/2.6.39-2011.06 suggests that there are more than zero interested in our 11.06 tarball at least ;).
On 1 July 2011 12:21, Andy Green andy.green@linaro.org wrote:
On 07/01/2011 08:14 PM, Somebody in the thread at some point said:
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 kernel/linux-linaro-android-$version with tags for each monthly release: android-v$version-$milestone-$buildcount kernel/$soc/linux-linaro-$version with tags for each monthly release: $bsp-v$version-$milestone-$buildcount kernel/$soc/linux-linaro-android-$version with tags for each monthly release: $bsp-android-v$version-$milestone-$buildcount
Comments?
It would be less ridiculous than issuing monthly tarballs for the kernel case.
We'd still release tarballs with this naming scheme, it would just be that the git tree locations would be consistent across all LTs.
~Deepak
On 1 July 2011 12:14, Deepak Saxena dsaxena@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 kernel/linux-linaro-android-$version with tags for each monthly release: android-v$version-$milestone-$buildcount kernel/$soc/linux-linaro-$version with tags for each monthly release: $bsp-v$version-$milestone-$buildcount kernel/$soc/linux-linaro-android-$version with tags for each monthly release: $bsp-android-v$version-$milestone-$buildcount
Comments?
So I haven't seen any feedback except Andy's on this. Anyone else have comments?
~Deepak
On Fri, 2011-07-08 at 12:35 -0700, Deepak Saxena wrote:
On 1 July 2011 12:14, Deepak Saxena dsaxena@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?
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
Would be maybe better. However, I'm not really that passionate about tag methods, as long as we have something that makes it clear what a release contains.
thanks -john
On 8 July 2011 12:50, john stultz johnstul@us.ibm.com wrote:
On Fri, 2011-07-08 at 12:35 -0700, Deepak Saxena wrote:
On 1 July 2011 12:14, Deepak Saxena dsaxena@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
-
Alexander Sack -
Andy Green -
Deepak Saxena -
john stultz