Hello Alexander,
On Wed, 15 Jun 2011 12:19:23 +0200 Alexander Sack asac@linaro.org wrote:
On Mon, Jun 13, 2011 at 2:41 PM, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
So, where do we go from here? Unless there's tip export feature directly out of remote repo for bzr (bzr export seem to requite local working copy), we'd need to play mirror, this time bzr, again %).
For the reason that it is trivial to do release manifests (pinned) I would really love to see bzr feature (as well as static tarball feature) to be available in repo and then use our repo mirror to do the mirroring in the cloud for that as well.
I'm not sure I understand exactly, do you mean repo as a (generic) repository or repo the Google's tool? I'm not sure it's really good idea (in terms of maintenance) to add bzr/tarball support to repo tool. Actually, per some recent discussion, there're good reasons to make a generic git mirror, and implement repo mirror using it.
As for release manifest, I guess I understand what you mean - we want to know from which components' versions given artifact is built, but neither I think that we can find generic solution for that (or that repo release manifest is ideal solution for this). IMHO, this should be handled on case by case basis. For example, for toolchain, it would make sense to include bzr revision from which it was built into tarball filename.
Could you check how much effort that is to add support to repo and to extend our cloud mirror to also understand bzr/tarballs?
For patching repo, we'd want to understand why we do it and for whom. Would Google accept it upstream? Somehow I doubt that, repo is a git tool which covers very specific needs of Android project. Otherwise, why would we want to maintain our own patchset on top of Google's hack-tool, which essentially just duplicates git submodules functionality?
As for our mirror service, adding such support in maintainable manner would require its complete rewrite (which will also allow to implement other functionality and improvements). Based on the currently scheduled blueprints related to cloud-buildd, closest time we can discuss and plan such rewrite in detail is at 11.08 sprint, and schedule implementation closer to the end of cycle.
Based on that we could decide whether we want to have a quick hack to get down the branching time quickly or if we wait till we can do this right using repo all together.
Thanks, Paul