[RFC] Consuming upstream tags in baserock

Paul Sherwood paul.sherwood at codethink.co.uk
Mon Jul 28 11:36:21 BST 2014


Hi
I saw some IRC discussion on this, and it's been an ongoing source of
complexity, so here's my 2cents:

- we aim for builds to be reproducible, which means knowing the exact
version of each component

- in some cases we would like to use upstream tags, but the fear is that
a tag may be occasionally moved or even deleted by upstream

- if we've taken the SHA1 for the tag, a move/deletion may lead to our
SHA1 being cleaned out later during a git gc (because it becomes
unreachable, hence cleanable).

- we've tried having a baserock/morph branch, and advancing it tidily so
that previous SHAs remain in the branch and hence aren't targets for gc.

- but baserock/morph can be moved too, and this can cause surprises
making it hard for a user to

I'd like to suggest we just make our own tags, containing enough meaning
to be useful for us and future maintainers of baserock systems.
Something like

baserock-<upstream-tag>-<short-sha-of-upstream-commit>

so for example Linux v3.16-rc6 could be tagged by us as

baserock-v3.16-rc6-9a3c414

This would prevent any cleanup by git, shield us from any
movement/deletion by upstream, and be parseable allow some validation to
ensure that neither upstream nor baserock itself has accidentally or on
purpose moved the tag (ie the short-sha should correspond with the head
commit)

I believe short SHA could be shorter than seven chars without any
realistic possibility of collisions, or longer if we're completely
paranoid.

br
Paul





More information about the baserock-dev mailing list