Skip to end of metadata
Go to start of metadata

For historical reasons, the GDP delivery team has been working with a repository/branch structure  that did  not scale. This limitation was identified before the release of GDP-ivi9 and now that the the project are heading towards GDP 10, it was about time to improve it. The branches minnowboardqemux86-64, porter and raspberrypi2 of the genivi-dev-platform repo are being deprecated in favour of the branch master.

As consequence of this change, new development and pull requests should be based off this new branch, starting today. The documentation, including instructions on how to build and run GDP, has been updated to reflect, among other news, that the init.sh script has been expanded to include selecting the hardware target.

Transition Timeline

The GDP delivery team has defined the following transition period to move from the former structure to the new one, again based on a single branch:

  • On May 31st it was announced the move to a single master among contributors through the genivi-projects mailing list.
  • The master branch was pushed to the official GitHub repository (genivi-dev-platform) on June 1st. It was communicated on the GDP weekly call and today to a wider audience through this post, after some additional testing.
  • The branches minnowboardqemux86-64porter and raspberrypi2 will be removed on June 6th, with the head of those branches preserved as tags. This means that contributors and users have a couple of days to test the new approach while still can use the former one to detect potential misbehaviour. This final step will also be announced.

How will this change affect you?

    • If you are a maintainer, the change should reduce the hassle with patch series. For instance, a patchset against qemux86-64 needed to be merged (rarely cleanly) across all other target branches. With this new approach, this issue will not longer exist. It also ensures that all targets are built against the same environment, e.g the same commit of meta-genivi-demo/poky.  However thought will have to be given on how to handle poky/meta-ivi upgrades correctly, especially when defining what targets are 'stable'.
    • Maintainers expect to reduce the confusion among contributors on which branch to use, which became an issue during the GDP-ivi9 release cycle. A single branch also means that if a contributor submits a generic patch, it will definitely be build-able by all targets once merged. All patches maintainers receive (especially to meta-genivi-dev) should be generic. And if not, they should be handled as such that non-relevant targets remain unaffected (sub-layers in meta-genivi-dev is one example of this).
    • Something similar to what contributors experienced was the case for users. Again, the confusion around which branch to use should be remedied. Users shouldn't have the worry about if the $target they want to build for is at the same level as any other $target. The use of release tags should also aid users who just want to go directly to a 'stable' build.

Changes in how Pull Requests (PR's) will he handled

For a start PR's to genivi-dev-platform.git will now be against this single master branch (the old advice was to use qemux86-64 for generic patchsets). In terms of CI/CD automation through go.cd, all PR's to meta-genivi-dev will be built against this master branch, with a pipeline dedicated to each $target. PR's to genivi-dev-platform.git are bit a more problematic, and the delivery team aim to achieve an automated system in which they can selectively (probably through the use of black/whitelist conditionals) trigger a targets pipeline if the PR is directly relevant.

For instance all submodule commits to meta-genivi-dev should be tested on all targets, however a PR for a meta-renesas submodule commit should only trigger $renesas pipelines. This decision will most likely have to be taken manually by maintainers to start with, or not at all (this will be a burden on the limited resources of go.genivi, but that will hopefully improve over time / resource expansion.)

One of the biggest hurdles for truly automating the PR procedure is how to tackle parallel PR's, i.e a patch series in which a change in meta-genivi-dev needs to be built against a change in genivi-dev-platform. As an example, recently the delivery team upgraded the Raspberry Pi kernel to 4.4. This required an upgrade to meta-raspberrypi submodule commit (GDP repo level) which contained the 4.4 recipe and a commit to meta-genivi-dev in which the kernel bbappend was amended to apply to 4.4.

Ultimately maintainers believe the solution to this parallel issue will be to unify genivi-dev-platfom & meta-genivi-dev into a singular repo (using sub layers and git submodules to handle dependencies), but in the meantime any thoughts around this are much appreciated. Please note in all cases a successful build in go.genivi does not mean a PR will automatically be merged, it should just be a requirement before review.

Call for testing

This is a change with a significant impact for those of you involved in the project. The GDP delivery team encourage you to test those everyday tasks you are familiar with, using this new master. Please report to them issues and potential improvements, specially during this week. Remember that you can contact the GDP Delivery Team through different channels, like IRC (#automotive in irc.freenode.net) or genivi-projects mailing list.