The process of updating definitions format

Pedro Alvarez pedro.alvarez at codethink.co.uk
Tue Mar 22 12:46:04 GMT 2016


On 22/03/16 11:25, Sam Thursfield wrote:
> On 22/03/16 10:43, Paul Sherwood wrote:

<snip>

>> I've held off proposing V9, V10, V11 since definitions is still
>> stuck at
>> V7.
>>
>> If we plough the spec forward on its own, I fear it will lose touch
>> with
>> reality.
> 
> I agree that a big delta between 'master' of definitions and the
> 'spec' repo isn't ideal. I have more faith than you in the people who
> review things on gerrit.baserock.org, I don't think anyone would lose
> touch with reality, but it's certainly not ideal.
> 
> Let's cut to the chase, which is to remove Morph from the equation.
> Since definitions V8 was proposed, nobody has sent any patches for
> Morph other than me, and so far I only got as far as cleaning up the
> historical mess of repocache code. So I propose we update
> definitions.git to version 8 now, and any Morph users won't be able to
> build 'master' until someone does a patch to fix Morph.
> 
> A lot of the wiki still refers to Morph so we'll need to deal with
> that somehow, perhaps by deleting all the horribly boring VM setup
> stuff and proposing folk use YBD instead.
> 
> Thoughts?


Some thoughts on this:

If we drop support for Morph (that means, Morph won't be able to build
definitions master any more) I'll face various problems with different
things I do with Baserock:

Infrastructure:

  - We have various services (Mason instances) making sure that
everything builds, we have some public ones (for x86_64 and x86_32)
and some non-public ones (for armv7lhf). They will become obsolete.

  - If Mason becomes obsolete, cache.baserock.org won't be populated
anymore with artifacts for x86_64, x86_32 and armv7lhf.

  - If we don't have services updating a shared and public cache, it
will slow us down. This will affect
      - Regular users building a system without a local artifacts cache
      - Me doing releases ('Me' because I think I'm the only one doing
regular releases)

      - Me and Sam doing Infrastructure upgrades

  - Given previous attempts, I don't feel comfortable with YBD to
upgrade infrastructure systems.


Genivi releases:

  - I won't be able to deploy Genivi systems, there is an issue
already created in YBD for that[1]
  - Genivi releases will take more time because there isn't a shared
cache available for YBD, nor services to automate the population of
this cache.
  - I won't be able to run 'scripts/licensecheck.py' in a reasonable
amount of time. It uses `morph get-repo` to reuse the git cache
already stored in the system. It will be possible to not use it, and
just do `git clone`, but that will make the process much slower.
  - I won't be able to generate some manifests required for Genivi
releases. I currently use `morph generate-manifest-genivi` for that.
  - Other scripts under 'scripts/' folder in definitions.git to help
us with releases might break.


There are probably more things to add to this list, things that we
have just ignored because we always assumed Morph as the build tool,
but I can't think of anything else at the moment. It would be good to
check all the things that read anything from /baserock/* meta files too.


[1]: https://github.com/devcurmudgeon/ybd/issues/167

PS: Mainly worried about Genivi releases given that I'll have to do
two in the following 4 weeks.


-- 
Pedro



More information about the baserock-dev mailing list