Skip to end of metadata
Go to start of metadata

(previously: GENIVI Development Platform management).  The weekly report have been moved to a separate page

GDP Delivery / Maintenance management

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

About tools: JIRA

Ticket types and principles – see GDP Scrum process.

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 - Getting issue details... STATUS  is an example. (commit message of PR can be amended to trigger the integration)

GDP-210 - Getting issue details... STATUS 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:

  • PR's to genivi-dev-platform, per target (x5, qemux86-64 here)

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 - Getting issue details... STATUS

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

Labels catalogue

These are legacy labels that might still exist.  The Scrum process (see above) uses less labels and only when necessary. 
There's no fully up-to-date list of what labels are currently still in use.

These are the previous JIRA labels used by the GDP maintenance team with some comments on the new process. 
(warning)  This could in time be moved/removed and replaced with current process only.  For a transition period, it's useful to still explain it however.

  • Deliverables
    • gdp: Genivi Development Platform: general topics about the project (Redundant.  The JIRA project is GDP)
    • gdp_master: content releated with the integration chain/pipeline (Assign to Component = GDP Master instead.  It's a bit redundant since everything goes to Master at some point)
    • sdk: software development kit (set Component = SDE instead)
    • meta-ivi: meta-ivi
    • spin: GDP spins contents (set Component = Spins instead)
  • GDP releases
            (set the "Fix Version" field of the JIRA ticket instead)
    • 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:
            (No such labels at the moment. Only the Component field which only has a handful of choices)
    • 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:
            (likely N/A.  Currently only yocto build is kept up to date)
    • baserock: workpackages related with Baserock project.
    • yocto: workpackages related with YOCTO project.
  • Events:
             (Not used. Typically releases coincide with AMM.  We plan using Fix Version and Release.
              If needed for a short time leading up to a minor event then a label could be used temporarily.)

    • 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
             (Not used.  The interest of PMO and the interests of the project should always be aligned.
              AGL is like any sister project / donor project / upstream.  No particular label needed)

    • agl: issues related with AGL.
    • pmo: tickets of interest for PMO
  • Delivery activities and processes:
            (Not used)
    • report: issues and pages/content related with reports. (set Component = Process, if it is a process issue)
    • roadmap: pages related with roadmaps and release planning. (set Component = Process, if it is a process issue)
    • cont_delivery: issues related with continuous delivery. (set Component = CIAT instead)
    • release: issues and tasks related with the release of products and projects.  (set Component = Process, if it is a process issue)
    • marketing: tasks related with marketing activities. (probably file ticket in other project, or simply no label)
    • testing: tasks related with tests and testing.  (set Component = CIAT)
    • management: issues related with management.  (set Component = Process, if it is a process issue)
    • delivery: delivery activities or issues related with the GDP delivery team.  (All tickets are handled in one way or another by the delivery team)
    • CIAT: continuous integration and automated testing  – (set Component = CIAT instead)
    • pipeline: tickets about pipelines in go.  (Create a ticket in TOOL with labels CIAT and pipeline)
  • Hardware
            (Not used)
    • peripherals: work done related with peripherals support or troubleshooting
    • target_board: work packages and issues related with the target boards (Just file a bug, target board mentioned in summary)

Labels for the GDP maintenance space are approved by the GDP maintenance project manager. 
(Still true, if labels are to be used, they should be documented)

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 - Getting issue details... STATUS
    • TOOL-57 - Getting issue details... STATUS 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:
  • 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.

Hardware support

Please refer to GDP releases for details on compatible hardware.
Hardware can be officially supported or community 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 Dragonboard 410c.

Other relevant topics

Redirections related with GDP

These are redirections that points key GDP pages:

#Wiki pageReal URLRedirection
(legacy or new URL
- in both cases redirected)
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 Unknown User (toscalix) 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?