Skip to end of metadata
Go to start of metadata

GDP delivery / maintenance status and discussions

GDP discussion meetings

GENIVI organizes a weekly call to discuss GDP topics. To participate please consider the following:

  • Date: Wednesdays
  • Time: 16:00 UTC
  • How to contact: GENIVI Webex
  • The GDP weekly report is presented during this call.

Activity reports

The GDP maintenance team provides to GENIVI a  weekly report. You can download the complete report:

2017 reports:

MonthDateReport in PDF

Report on Wiki



 Week 15Week 15
 Week 14Week 14
 Week 13Week 13




Week 12Week 12
Week 11Week 11
 Week 10Week 10
 Week 9Week 9
 Week 8Week 8






 Week 7Week 7
 Week 6Week 6


Week 5Week 5
 Week 4Week 4



  Week 3Week 3
 Week 2Week 2
  Week 1Week 1

2016 reports:

(green star) First report from Pelagicore AB

(star) Last report from Codethink Ltd


GDP Delivery / Maintenance management

The GDP team uses JIRA to manage the requests, requirements, actions and bugs related with the project.

About tools: JIRA

JIRA issue types for GDP maintenance project

There are four main issue types:

  • Epic: milestone. Main topic the GDP maintenance team will be working on for some time composed of several tasks/features.
  • Task: default work package unit
  • Feature: development, integration or deployment of a new functionality. Since this is a maintenance project, we do not expect many of these.
  • Bug: misfunction or problem to be fixed.

JIRA status used in GDP maintenance project

The GDP maintenance team work assign to each issue one of the following status

  • Request / Analysis: any work that comes from a contributor or internally needs to be evaluated before assuming the commitment to execute it. This stage will be assigned to those work packages that are being evaluated.
  • Todo / Backlog: when the work packages are approved, they get into the backlog of the team.
  • In progress: work that is being done. Since this is a maintenance project, execution does not depend only on us, but also on the committer or developer. This state also reflect those cases in which maintainers are waiting for feedback from those.
  • In Review: acceptance checks before considering a task done.
  • Done / Closed: Work packaged has been finished or, for a variety of reasons, won't be done. Closed issues can be reopened.

As you can see, the proposed status left room for interpretation since we followed a flexible approach. We expect to clarify or increase the number of them when needed.

Label policy: content up to date vs content out of date

Some of the content related with GDP refers to previous versions while some other pages apply to the latest version or to any version. How do readers know if the content is still up to date or applicable today? ingeneral, the following rules apply:

  • Pages with the label gdp_x where x is the latest version, are up to date or applicable today.
    • In order to know which GDP version is the latest check the Download page or the feature page with the highest version number.
  • Pages with the label gdp_x and gdp_(x-n) are content applicable to the current version of GDP and previous ones.
  • Pages with the label gdp_(x-n) but not gdp_x are content applicable only to previous GDP versions, not to the latest one.
    • They are still in the wiki because an update is expected or because it describes an interesting topic that would be good to update.
  • Pages with the label gdp without any label referring to a specific version is content relevant to any version of GDP delivered so far.

About tools: Github

Integration between GitHub and JIRA

Relation with JIRA:


  • Create a pull request to a repo
  • In the commit description, add a JIRA ticket ID between [] like GDP-210
  • Go to the JIRA ticket GDP-210
  • You now can see a new section on the right side bar called "Development" with information about your commit: repo, commit link, status, etc.
  • Note: adding the issue ID to the comment section of a pull request is irrelevant for this purpose.
  • GDP-159 - meta-rvi yocto layer merging Done  is an example. (commit message of PR can be amended to trigger the integration)


GDP-210 - Test integration between JIRA and Github Done has been created for you to test the integration. Use it in your pull requests to GENIVI repo to test the feature.

Integration between GitHub and Confluence

There are configured the following direct links between Confluence and GitHub, in order to reduce the effort to refer to this external tool:

Remove spaces and change "at" by @

The above works for every GitHub repository. Other links can be created. Please contact the GDP delivery team.

Integration between GitHub and

Basic functionality has been achieved between github pull requests (PR's) and the genivi server. Currently this integration is quite basic/inefficient.

There are two sets of pipelines:

  1. PR's to meta-genivi-dev, built against master of genivi-dev-platform, per target (x4, qemux86-64 here)
  2. PR's to genivi-dev-platform, per target (x4, qemux86-64 here)

The aim is to work on the automation, ultimately increasing efficiency by avoiding redundant builds. Incoming PR's need to be parsed and built selectively based on content.

We don't want to test 'non-code' changes (e.g. README), and we don't want to necessarily build against all targets (e.g. BSP upgrade). This process will mature over time

There is also the issue of 'parallel' PR's which require a PR in meta-genivi-dev to be tested with a corresponding PR to genivi-dev-platform (e.g. bsp update + append update)

This is a known issue, which isn't unique to GDP and arises due to the nature of yocto meta layers and cross repo dependencies. This scenario isn't automated as of yet.


The integration allows for the build status to be seen directly in the Github PR page, for example here

As a first step in checking 'pre-merge', it is expected all pipelines will pass before a PR can be considered for review/merge. However the CI is not bulletproof.

If a PR produces a failing pipeline, the logs need to be checked to clarify that the PR caused the issue. If the error is external, then a maintainer is expected to investigate.

GDP-231 - GDP CI: integrate Master with Done

A more detailed information about the integration between and GitHub can be found in the info page.

Labels catalogue

These are the JIRA labels used by the GDP maintenance team:

  • Deliverables
    • gdp: Genivi Development Platform: general topics about the project
    • gdp_master: content releated with the integration chain/pipeline
    • sdk: software development kit
    • meta-ivi: meta-ivi
    • spin: GDP spins contents
  • GDP releases
    • gdp_v7: issues related with GDP based on Baseline v7.
    • gdp_v9: issues related with GDP based on Baseline v9.
    • gdp_v10: issues related with GDP based on Baseline v10.
    • gdp_v11: issues related with GDP based on Baseline v11.
  • Expert Groups and components related labels:
    • lifecycle: issues related with the integration of the Lifecycle group into GDP
    • license_compliance: issues related to (FOSS) license compliance
    • compliance: compliance with GENIVI specs.
    • baseline: content and tasks related with GENIVI basline
    • rvi: remote vehicle information component related task
    • nsm: component Node State Manager.
    • fsa: fuel stop advisor
  • Technologies:
    • baserock: workpackages related with Baserock project.
    • yocto: workpackages related with YOCTO project.
  • Events:
    • event: issues related with any event or conference
    • 13th_amm: content related with the 13th AMM event that took place in Seoul.
    • 14th_amm: issues related with the 14th All-Members Meeting, that took place in Paris in April 26th-29th
    • 15th_amm: issues related with the 15th GENIVI All Members Meeting that took place in Burlingame in October
    • Meeting-notes: wiki pages and tasks related with minutes from meetings.
  • Organizations and departments
    • agl: issues related with AGL.
    • pmo: tickets of interest for PMO
  • Delivery activities and processes:
    • report: issues and pages/content related with reports.
    • roadmap: pages related with roadmaps and release planning.
    • cont_delivery: issues related with continuous delivery.
    • release: issues and tasks related with the release of products and projects.
    • marketing: tasks related with marketing activities.
    • testing: tasks related with tests and testing.
    • management: issues related with management.
    • delivery: delivery activities or issues related with the GDP delivery team.
    • CIAT: continuous integration and automated testing
    • pipeline: tickets about pipelines in go.
  • Hardware
    • peripherals: work done related with peripherals support or troubleshooting
    • target_board: work packages and issues related with the target boards

Labels for the GDP maintenance space are approved by the GDP maintenance project manager.

About tools: other tools

GDP Delivery Team has reported in several ways the tools and processes around those tools that are required to improve efficiency and scalability. These are some of those reported needs

  • Overview sent to the genivi-projects mailing list in June 2016.
    • Deployment infrastructure: OSSINFR-103 In Progress
    • TOOL-57 To Do As main users of, the GDP Delivery Team has several requests around this tool to improve efficiency and scalability, mainly.
  • Tools Team f2f meeting at 15th AMM. Overview of the needs (last part of the slide deck).
  • Final report of GDP year 1 as OPen Source project. Check the Infrastrucutre and Services section.


Master / Maintenance Branch Policies

With GDP implementing a rolling release based model, the git structure / policies are as such:

  • Master: The default branch for genivi-dev-platform.git & meta-genivi-dev.git
    Work during release cycles is completed in this branch, once a 'release' candidate is declared master is branched to a 'release' branch, which becomes the current maintenance branch.
    Currently (and following general yocto practices) the version of the GDP in master is linked by the underlying baseline (meta-ivi) and the yocto release below it (poky/OE), once a release is
    declared this inheritance is used to define the version. It is expected that any new package contributions are sent as patches / PR's against master. Due to being a branch in constant flux in terms of yocto versioning, situations may occur in which not all target hardware is supported due to the relevant BSP layer not supporting the required version of yocto.
  • Maintenance: The current maintenance branch of genivi-dev-platform & meta-genivi-dev.git
    The maintenance branch is the name given to the currently supported 'release' branch of GDP
    Once a new release is declared and branched from master, the maintenance title is transferred.
    Only bug/security fixes or specific backport patches / PR's should be based against this branch.
    It is expected that a user looking for a 'stable' GDP build (or requiring a certain version of a package)
    would use the maintenance branch.

Issues priority

  1. Priority: by default, all issues will be created with priority set as low.
  2. If an issue is relevant, Medium priority can be used.
  3. The use of  High and Highest priority is reserved to the GDP Delivery Team

Requests for the next GDP version (Master requests)

  • Master requests are collected in a specific task: GDP-154 Done .
  • They are processed by the GDP team and discussed through the mailing list
  • Once accepted, each subtask is moved as task and splitted into subtasks if it is big enough to be done in several steps.
  • If it is related to a specific release, a FixVersion is added and a deadline.
    • PMO manages high level requests/goals and coordinates them with the GDP team at the PMO call. Once one of those high level requests can be executed, the GDP Delivery team takes control of it.

GDP Release

GDP is developed in the open and the release is a collaborative effort. In order to understand how GDP is released please check our GDP Release Howto. After each release, you can see the issues completed in the GDP Release Report: Tasks Completed.

Ports to boards

In general, the GDP Delivery Team maintains the following ports to development boards

  • Intel architechture
    • Minnowboard MAX
    • Minnowboard Turbot.
  • ARM
    • Raspberry Pi2
    • Raspberry Pi3
    • Renesas Porter
    • Renesas Silk
  • Other boards maintained by the community
    • Renesas Koelch. Maintainer: Stephen Lawrence
    • Qualcomm Dragonboard 410c. Maintainer: Changhyeok Bae.

Check the GDP Release page to find out the information about each target board port. QEMU is also supported.


In order to add new ports to the list officially maintained, the process is the following.

  1. A person steps up and communicate his/her intention to support a new port.
  2. The port is maintained consistently by a community member.
  3. The port becomes part of the release, showing a commitment by the maintainer to attach to the release processes.
  4. The Delivery Team buys a couple of boards and help the maintainer in testing and reviewing patches for the specific board.
  5. The port becomes part of the official duties of the GDP Delivery Team, helping the maintainer by taking over his work if this one prefer to focus on other topics.

The above process worked very well for RPi2 first, then RPi3 and currently it is on its way for Dragonboard 410c.

Other relevant topics

Redirections related with GDP

These are redirections that points key GDP pages:

#Wiki pageReal URLRedirection (shorter/new URL)
1GDP landing (home) page
2GDP Download
3Release announcement
4GDP-ivi7 feature page
5GDP-ivi9 feature page
6GDP 11 feature page
7GDP Roadmap
8GDP Master
9GDP releases
10GDP Out There
11GDP Management
12GDP In detail
14GDP bug tracker

List of pages and other information sources to measure the impact of GDP releases

These are the pages and social media network/messages that GENIVI tracks initially to evaluate the impact of our marketing efforts, our success in our content strategy and the general impact of the project. In order to evaluate the usage of our deliverables and the profile of our users further measures needs to be taken. A different strategy is needed to measure the number and profile of our contributors.


#Wiki PageReal URLRedirectionComment
1Release Announcement (I) release announcement. The number of hits reflect how good our marketing effort has been. The amount of time spent on the page will determine the real interest in the release (content). How many clicks we get will help us understand how many people is interested in the software compared to only the news. This page is different in each release.
2GDP landing (home) page home page is not relevant for releases but during the release cycle it will determine if the interest in the project is growing or not. We should see a correlation between the evolution of this page and the evolution in the hits on the release announcement. Anomalies in this correlation should be investigated carefully.
3GDP Download analysis of this page will determine the amount of people that consumes each release. It will also determine which images are the most popular ones. It will also help us to determine who wants to download the image vs who goes to check the instructions to use ie. It is very interesting to analise how visitors reach this page: directly, through the release announcement or through other pages.
4Release announcement (II) the content is cloned, some visits might hit this page instead of the main announcement. There should be very few, but countable. This page is different in each release.
6GDP 11 feature page is the page that describes the release. Do users download first the software and consume the instructions to run it or do they check what the release brings first? The second group are usally more senior devs that do not follow the project or Yocto closely. This page is different in each release.
8GDP Master on this page and permanence time will provide us an initial idea of how popular Master is. We can compare it to the downloads.
9GDP releases page does not play a relevant role today in the critical contents path during release time since we are driving users directly to the target board pages. Its relevance should increase with the increase of deliverables like spins.
12GDP In detail GDP strategy to capture new users, this is the last step of the first stage. The ratio between those users that get here compared to those who read the release abnnouncement and download the distro will determine how well we are doing in the fidelization of first time users. It is also very interesting to evaluate where do visitors go next.
13GDP FAQ in the case of the home page, hits here define the interest of people in the project in general. In theory, there should be a correlation between the hits and permanence time on this page during a release cycle and the number of hits in the release annoucnement. The interest in the project increases over time and it is reflected in the release annoucnement.
14TwitterRD-1 / RT / RD+1 messages There should be a correlation between our success in Twitter, specially in those messages and the hits experienced in the release announcement. It is interesting to analyse prints vs variation in the number of followers. How many people reach the release announcement or download page from twitter?
15LinkedinRD-1 / RT / RD +1 messages There should be a correlation between our success in Twitter, specially in those messages and the hits experienced in the release announcement. It is interesting to evaluate the differences between the behaviour in Linkedin, Twitter and G+. How many people reach the release announcement from Linkedin?
16G+RD-1 / RT / RD +1 messages Measuring hits in the release announcement coming from G+ will help us to evaluate the real value of G+ among embedded engineers. G+ is not about hits but about the specific profile of people that use it.
17GDP bug tracker page is interesting to track to compare it with support requests on MLs, bugs opened and pre-releases impact in order to find out if the beta testing program is improving. It is also interesting to evaluate the impact of the call for testing calls in pre-releases.

In general, it is also interesting to find out who reaches the above pages through the direct link or through the redirection. Redirections are used in our release campaigns while direct links are the ones shown in searches through search engines. Studying the above numbers will not provide a full picture but studying their evolution will tell us if we are improving or not and where.

GDP portfolio design

Background statements defined by GENIVI, after a PdM workshop:

  • GDP goal is to bring innovation into the automotive industry.
  • GDP targets application developers.

This proposal was sent to the mailing list by Agustin Benito Bethencourt before the PdM workshop. A presentation about this particular topc was part of the 15th AMM: GENIVI software as portfolio. Where can we go next? How?