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-tagging-repo
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 ;-).

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog



--
Alexander Sack
Director, Linaro Platform Engineering
http://www.linaro.org | Open source software for ARM SoCs
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog