Hello,
I recently got https://blueprints.launchpad.net/linaro-infrastructure-misc/+spec/rebasing-t... to verify current state of affairs with repo handling of SHA revisions for commits which have underlying tags. The blueprints contains full details, let me in this report mail cover just we most important bits.
1. We have been having problem with repositories used in Android releases being rebased later for a long time.
2. Trying to resolve that, we established policy that any revision used in a release must be tagged, to make sure that exact revision stays across rebases.
3. That didn't really work well with "repo" tool from ~1.5yr ago, because it did not fetch tags by default, so rebased revisions were still unreachable.
4. We did our patching to repo and submitted it to Google, which then was lost in great kernel.org demise of 2011, and later they rejected it telling they'd do it in different way.
5. Fast forward to modern time, I verified that repo v1.12.2 works as expected wrt to fetching commits by SHA revs, if they have underlying tag, so we're covered for policy of p.2.
6. However, few repos were found to still be rebased without tagging release revisions. To address that, following options are proposed:
a) Disallow to use SHA revs in release manifests. Granted, that would make more effort to do a release then just get pinned manifest of some build, but may improve release process by prompting to ensure that releases are made from Android Team managed mirrors of repositories, and that all such repositories are tagged in consistent manner (which how upstream does it).
b) Verify that each SHA has underlying tag. A bit more challenging technically (i.e. possibility for unexpected behavior), and misses the chance to move release process to a new level, but should be still doable.
Note that both choices preserve ability to rebase repositories, which is considered an important developers' right ;-).
On 28 March 2013 17:12, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
Hello,
I recently got
https://blueprints.launchpad.net/linaro-infrastructure-misc/+spec/rebasing-t... to verify current state of affairs with repo handling of SHA revisions for commits which have underlying tags. The blueprints contains full details, let me in this report mail cover just we most important bits.
- We have been having problem with repositories used in Android
releases being rebased later for a long time.
- Trying to resolve that, we established policy that any revision used
in a release must be tagged, to make sure that exact revision stays across rebases.
- That didn't really work well with "repo" tool from ~1.5yr ago,
because it did not fetch tags by default, so rebased revisions were still unreachable.
- We did our patching to repo and submitted it to Google, which then
was lost in great kernel.org demise of 2011, and later they rejected it telling they'd do it in different way.
- Fast forward to modern time, I verified that repo v1.12.2 works as
expected wrt to fetching commits by SHA revs, if they have underlying tag, so we're covered for policy of p.2.
- However, few repos were found to still be rebased without tagging
release revisions. To address that, following options are proposed:
a) Disallow to use SHA revs in release manifests. Granted, that would make more effort to do a release then just get pinned manifest of some build, but may improve release process by prompting to ensure that releases are made from Android Team managed mirrors of repositories, and that all such repositories are tagged in consistent manner (which how upstream does it).
To make this happen we should make sure that any repository that get into Android manifest are mirrored in android.git.linaro.org for us to create tags. Here are the number of projects we pull in from external git repository: 15 - git.linaro.org 6 - linaro-private.git.linaro.org 1 - github 1 - igloocommunity
Is it possible to have restricted gits in a.g.l.o similar to linaro-private.git.linaro.org ?
b) Verify that each SHA has underlying tag. A bit more challenging technically (i.e. possibility for unexpected behavior), and misses the chance to move release process to a new level, but should be still doable.
Can we do something smart here ? Can the git repository be configured in such a way that we mirror the external repositories and during syncing up with the mirror we create a tag (if it doesn't exist ) after syncing from these upstream git.
Note that both choices preserve ability to rebase repositories, which is considered an important developers' right ;-).
-- Best Regards, Paul
Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
linaro-android mailing list linaro-android@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-android
Hello,
On Thu, 4 Apr 2013 17:48:32 +0530 Vishal Bhoj vishal.bhoj@linaro.org wrote:
On 28 March 2013 17:12, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
Hello,
I recently got
https://blueprints.launchpad.net/linaro-infrastructure-misc/+spec/rebasing-t... to verify current state of affairs with repo handling of SHA revisions for commits which have underlying tags. The blueprints contains full details, let me in this report mail cover just we most important bits.
- We have been having problem with repositories used in Android
releases being rebased later for a long time.
- Trying to resolve that, we established policy that any revision
used in a release must be tagged, to make sure that exact revision stays across rebases.
- That didn't really work well with "repo" tool from ~1.5yr ago,
because it did not fetch tags by default, so rebased revisions were still unreachable.
- We did our patching to repo and submitted it to Google, which
then was lost in great kernel.org demise of 2011, and later they rejected it telling they'd do it in different way.
- Fast forward to modern time, I verified that repo v1.12.2 works
as expected wrt to fetching commits by SHA revs, if they have underlying tag, so we're covered for policy of p.2.
- However, few repos were found to still be rebased without tagging
release revisions. To address that, following options are proposed:
a) Disallow to use SHA revs in release manifests. Granted, that would make more effort to do a release then just get pinned manifest of some build, but may improve release process by prompting to ensure that releases are made from Android Team managed mirrors of repositories, and that all such repositories are tagged in consistent manner (which how upstream does it).
To make this happen we should make sure that any repository that get into Android manifest are mirrored in android.git.linaro.org for us to create tags.
Yes, we've talked previously that this should be the case, now we can go on and actually enforce it (i.e. error out if release build pull something outside android.git.linaro.org/linaro-private.git.linaro.org).
Here are the number of projects we pull in from external git repository: 15 - git.linaro.org 6 - linaro-private.git.linaro.org 1 - github 1 - igloocommunity
Is it possible to have restricted gits in a.g.l.o similar to linaro-private.git.linaro.org ?
What I can say for sure is the whole git.linaro.org/android.git.linaro.org matter is currently in flux, being migrated to EC2 and new VCS management platform (Rhodecode). So, let's just assume it's not possible right now and won't be possible to do in the near future (makes no sense to do on old setup, new one is not ready and may need some time to polish all features).
But working on mirroring all the other servers is already great way towards more organized stuff. So, if that sounds good, I'm ready to process a ticket which says to mirror which of those git.linaro.org/github/igloocommunity projects where on a.g.l.o and add the check as described above to android-build.
b) Verify that each SHA has underlying tag. A bit more challenging technically (i.e. possibility for unexpected behavior), and misses the chance to move release process to a new level, but should be still doable.
Can we do something smart here ? Can the git repository be configured in such a way that we mirror the external repositories and during syncing up with the mirror we create a tag (if it doesn't exist ) after syncing from these upstream git.
It's not clear what exactly would be tagged here. Latest HEAD of master branch of upstream repo? What if revision you need to use is not the latest? What if it's in different branch? Otherwise, that's pretty doable, the question is how to make it actually useful (vs just proliferating useless tags).
Hi,
thanks for the great write up.
I am for option b). Reason: If we solve this problem invisibly on the import bot side we won't need to worry about tools and how to allow developers to interact with a release system that would auto tag stuff and change all the manifests.
Also, option b) will solve our problem with random unavailability of our daily builds upon rebase - if done right. I still consider reproducible daily builds an important feature of continuous/daily building :) and option a) wouldn't give us that easily...
In other words, I believe option b) will solve the same class of problems and more for the same or, more likely, lower costs.
BTW, I didn't get what you mean with "move release process to a new level". Maybe expand a bit more on that.
On Thu, Mar 28, 2013 at 12:42 PM, Paul Sokolovsky < paul.sokolovsky@linaro.org> wrote:
Hello,
I recently got
https://blueprints.launchpad.net/linaro-infrastructure-misc/+spec/rebasing-t... to verify current state of affairs with repo handling of SHA revisions for commits which have underlying tags. The blueprints contains full details, let me in this report mail cover just we most important bits.
- We have been having problem with repositories used in Android
releases being rebased later for a long time.
- Trying to resolve that, we established policy that any revision used
in a release must be tagged, to make sure that exact revision stays across rebases.
- That didn't really work well with "repo" tool from ~1.5yr ago,
because it did not fetch tags by default, so rebased revisions were still unreachable.
- We did our patching to repo and submitted it to Google, which then
was lost in great kernel.org demise of 2011, and later they rejected it telling they'd do it in different way.
- Fast forward to modern time, I verified that repo v1.12.2 works as
expected wrt to fetching commits by SHA revs, if they have underlying tag, so we're covered for policy of p.2.
- However, few repos were found to still be rebased without tagging
release revisions. To address that, following options are proposed:
a) Disallow to use SHA revs in release manifests. Granted, that would make more effort to do a release then just get pinned manifest of some build, but may improve release process by prompting to ensure that releases are made from Android Team managed mirrors of repositories, and that all such repositories are tagged in consistent manner (which how upstream does it).
b) Verify that each SHA has underlying tag. A bit more challenging technically (i.e. possibility for unexpected behavior), and misses the chance to move release process to a new level, but should be still doable.
Note that both choices preserve ability to rebase repositories, which is considered an important developers' right ;-).
-- Best Regards, Paul
Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
On Tue, 9 Apr 2013 00:21:01 +0200 Alexander Sack asac@linaro.org wrote:
Hi,
thanks for the great write up.
I am for option b). Reason: If we solve this problem invisibly on the import bot side we won't need to worry about tools and how to allow developers to interact with a release system that would auto tag stuff and change all the manifests.
Well, I don't think that it will be possible to (reasonably) auto-tag things, see my reply to Vishal. The whole idea of tagging is that it's done by human to signify specific state of the code (like, release ready).
In one of previous discussions, I mentioned some possibility of sensible auto-tagging - tag entire Android tree on each build. Zach didn't like that, and technically, we're pretty far away of doing that (not clear how to handle that for repo (vs single git tree), we don't have write access on build slaves due to security issues).
Also, option b) will solve our problem with random unavailability of our daily builds upon rebase - if done right. I still consider reproducible daily builds an important feature of continuous/daily building :) and option a) wouldn't give us that easily...
In other words, I believe option b) will solve the same class of problems and more for the same or, more likely, lower costs.
So, there must be misunderstanding regarding what I proposed re a) and b). Let me give examples:
a): For release builds (other builds unaffected):
Only manifest entries of the following form are accepted:
<project path="packages/apps/0xbench" name="platform/packages/apps/0xbench" revision="refs/tags/relXX" />
if revision doesn't start with "refs/tags/", build is rejected.
b): For release builds (other builds unaffected):
Only manifest entries of the following form are accepted:
<project path="packages/apps/0xbench" name="platform/packages/apps/0xbench" revision="0123abcd..." />
Where revision "0123abcd..." must have an underlying tag in the repository platform/packages/apps/0xbench.
So, both choices deal with checking that tags exist, not creating them. The latter expected to be still human task, sensible auto-tagging would take much more effort to design and implement.
BTW, I didn't get what you mean with "move release process to a new level". Maybe expand a bit more on that.
Well, one example is given in response to Vishal - we talked about all git trees to be mirrored in android.g.l.o, but that doesn't seem to be the case so far. If we go for comprehensive mirroring (and enforcing it), we'll be sure that no 3rd party will be gone behind our fit. If we go for Android release manager to add release tags to repositories (and enforcing that), then we'll be immune to rebasing issues for releases. If we design and implement automatic tagging of each build, we'll be able to reproduce each single build, and do other cool things, like easily see diff between any 2 builds across entire Android tree. Etc., etc.
On Thu, Mar 28, 2013 at 12:42 PM, Paul Sokolovsky < paul.sokolovsky@linaro.org> wrote:
Hello,
I recently got
https://blueprints.launchpad.net/linaro-infrastructure-misc/+spec/rebasing-t... to verify current state of affairs with repo handling of SHA revisions for commits which have underlying tags. The blueprints contains full details, let me in this report mail cover just we most important bits.
- We have been having problem with repositories used in Android
releases being rebased later for a long time.
- Trying to resolve that, we established policy that any revision
used in a release must be tagged, to make sure that exact revision stays across rebases.
- That didn't really work well with "repo" tool from ~1.5yr ago,
because it did not fetch tags by default, so rebased revisions were still unreachable.
- We did our patching to repo and submitted it to Google, which
then was lost in great kernel.org demise of 2011, and later they rejected it telling they'd do it in different way.
- Fast forward to modern time, I verified that repo v1.12.2 works
as expected wrt to fetching commits by SHA revs, if they have underlying tag, so we're covered for policy of p.2.
- However, few repos were found to still be rebased without tagging
release revisions. To address that, following options are proposed:
a) Disallow to use SHA revs in release manifests. Granted, that would make more effort to do a release then just get pinned manifest of some build, but may improve release process by prompting to ensure that releases are made from Android Team managed mirrors of repositories, and that all such repositories are tagged in consistent manner (which how upstream does it).
b) Verify that each SHA has underlying tag. A bit more challenging technically (i.e. possibility for unexpected behavior), and misses the chance to move release process to a new level, but should be still doable.
Note that both choices preserve ability to rebase repositories, which is considered an important developers' right ;-).
-- Best Regards, Paul
Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
Hi,
On 28 March 2013 12:42, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
a) Disallow to use SHA revs in release manifests.
b) Verify that each SHA has underlying tag.
I'm in favor of b) mostly because AOSP tends to put in SHAs for kernels. We should remain compatible...
ttyl bero
linaro-android@lists.linaro.org
-
Alexander Sack -
Bernhard Rosenkränzer -
Paul Sokolovsky -
Vishal Bhoj