Blog

GDP 11 released

The full release of GDP 11 is now available and can be found on the download page. Since the October AMM, GDP 11 has undergone extensive testing to confirm stability and is proven on additional hardware targets. Like the previous release candidate, GDP 11 includes a GENIVI-branded GUI and configurable application launcher, an enriched Software Development Environment (including SDK) and increased vehicle connectivity with Remote Vehicle Interaction Core and SOTA Client software. 

GDP 11 highlights include:

  • Easier to install, build and use
  • Compatible with several Intel and ARM based development boards including the low-cost Raspberry Pi boards
  • Developed in an open and collaborative environment, following the best practices of any reputed FOSS community
  • Combines the latest stable Open Source automotive software components with the latest stable generic Linux based software provided by the Yocto project

Those with Yocto knowledge can build this release from scratch using the GDP 11 build instructions. Other links of interest are:

  • GDP 11 Feature Page provides details on what is new in this release.
  • GDP Releases wiki page where you can find information on how to run the available GDP 11 ports to differeny hardware platforms. This is of interest to those application developers who are not familiar with Yocto.
  • GDP Master wiki page, with instructions on how to build GDP from scratch with support to a wider range of target boards with Yocto knowledge.
  • GDP 11 Bug Tracking system for those wishing to provide feedback in the form of bug reports, new feature requests, and any other comments on this release. GENIVI welcomes all type of inputs from the community so we can make future GDP releases better.
  • GDP Roadmap for information on the upcoming GDP releases.

The GENIVI community welcomes all member and open source community efforts to further enhance the GDP making it a fully featured and continuously enhanced development platform product. Additionally, GENIVI appreciates assistance in the areas of testing, bug reporting, patching and new feature requesting to advance GDP development (technical discussions occurring on genivi-projects email list and on Jira trackers).

Release notes courtesy of Traci Renner.

Delivered and enhanced by the GENIVI community, the GENIVI Development Platform (GDP) has progressed significantly moving from a demonstrator to a true development platform with the new GDP 11 Release Candidate 3 (RC3) . Like the previous release candidate, GDP 11 RC2, the GDP 11 RC3 includes a number of new features including an enhanced user experience with a GENIVI-branded GUI and configurable application launcher. Also included in GDP 11 RC3 is an enriched Software Development Environment (including SDE) and increased vehicle connectivity with Remote Vehicle Interaction Core and SOTA Client software. All of these new features will be highlighted at the October All Member Meeting (AMM). Additionally, the GDP 11 RC3 containing this new user experience will receive further testing to gain the stability needed for a full release after the AMM.

 

GDP 11 RC3 highlights include:

  • Easier to install, build and use

  • Successful deployment on the low-cost Raspberry Pi boards

  • Developed in an open and collaborative environment, following the best practices of any reputed FOSS community

  • Combines the new UI and application launcher with the latest stable Open Source automotive software components and the latest stable generic Linux based software provided by the Yocto project

  • Consistent with v. 11 of the GENIVI Platform Compliance Specification and its related Baseline

 

GENIVI has provided two release candidates for prospective adopters who may have different goals. GDP 11 RC2 gives adopters a more stable experience given the weeks of testing on multiple hardware boards, though without the new UI and application launcher. GDP 11 RC3 gives adopters the absolute latest set of features including the new UI and application launcher, though the stability of this candidate is still being proven.

 

Those with Yocto knowledge can build this release candidate from scratch from the GDP Master, where work is currently being done to support multiple Intel and ARM-based development boards. Other links of interest are:

  • GDP 11 RC3 Feature Page provides details on what is new in this pre-release.

  • GDP Releases wiki page where you can find information on how to run the available GDP 11 RC2, RC3 ports to different boards and the new SDE . This is of interest to those application developers who are not familiar with Yocto.

  • GDP Master wiki page, with instructions on how to build GDP from scratch with support to a wider range of target boards with Yocto knowledge.

  • GDP 11 Bug Tracking system for those wishing to provide feedback on this release. The GDP Delivery Team welcomes bug reports.

  • GDP Roadmap for information on the upcoming GDP 11 release.

 

The GENIVI community welcomes all member and open source community efforts to further enhance the GDP making it a fully featured and continuously enhanced development platform product. Additionally, GENIVI appreciates assistance in the areas of testing, bug reporting and patching to advance GDP development.

GENIVI Marketing Team

The GENIVI Alliance is publishing a new release candidate, GDP 11 RC2, to improve the stability of the GENIVI Development Platform (GDP) base system while increasing the number of boards on which the GDP is available. The GDP 11 RC2 includes a number of bug fixes, improvements across the system and more stable ports to several development boards. GENIVI has decided to delay the full GDP 11 release to allow for the addition of a significant feature enhancement in the form of a new user interface and application launcher.

In order to enhance the user experience and to ease adding new applications to the GDP, the GENIVI Graphics Team has provided a brand new user experience which is being integrated into the GDP RC2. This significant feature enhancement will be highlighted at the upcoming GENIVI All Member Meeting (AMM) and will include a GENIVI-branded GUI and configurable application launcher. The updated GDP containing this new user experience will receive additional testing to gain the stability needed for a full release after the AMM.

 GDP RC2 includes the latest bug fixes from meta-ivi along with a variety of other bug fixes and small improvements across the system with more stable ports to the development boards listed below. There is also a port to QEMU for those who want to take a quick look at what GDP base system is today.

  • Intel Minnowboard MAX

  • Raspberry Pi2 and 3

  • Qualcomm Dragonboard 410c

Those with Yocto knowledge can build this second release candidate from scratch from the GDP Master, where Renesas Porter and Silk are also supported. Other links of interest are:

  • GDP 11 RC2 Feature Page provides details on what is new in this pre-release.

  • GDP Releases wiki page where you can find information on how to run the available GDP 11 RC2 ports to different boards. This is of interest to those application developers who are not familiar with Yocto.

  • GDP Master wiki page, with instructions on how to build GDP from scratch with support to a wider range of target boards with Yocto knowledge.

  • GDP 11 Bug Tracking system for those wishing to provide feedback on this release. The GDP Delivery Team welcomes bug reports.

  • GDP Roadmap for information on the upcoming GDP 11 release.

The GENIVI Alliance appreciates all member and community efforts testing the GDP 11 RC2 and will soon announce a final release candidate with the new user interface for testing.

The GENIVI Alliance is happy to announce immediate availability of the first release candidate (RC1) of the GENIVI Development Platform, GDP 11. To provide the highest possible quality of final release, the GDP Delivery Team is calling upon the GENIVI community and others interested in Open Source software for automotive to test the GDP 11 RC1, prior to final release in the next few weeks.

GDP RC1 includes ports to QEMU, MinnowBoard MAX (compatible with the new Minowboard Turbot) and Raspberry Pi 2 and 3. This first candidate brings several improvements from the latest stable Yocto release 2.1.1 including:

  • the latest meta-ivi pre-release M-0.2 published last week (Yocto and Baserock versions)
  • bug fixes detected during the Beta pre-release
  • enhancements as a consequence of testing GDP with the target boards
  • the latest vc4 drm kernel drivers to support the RPi official 7" touchscreen.

Download GDP RC1 port for your favorite board or QEMU. Those with Yocto knowledge can build from scratch this first release candidate from GDP Master, where work is currently being done to support Renesas Porter, Silk and Qualcomm Dragonboard 410c boards which will take precedence in the final release. Other links of interest are:

  • GDP 11 RC1 feature page is the place to read about what is new in this pre-release.
  • GDP releases wiki page where you can find information about how to run the available GDP 11 RC1 ports to different boards. This is of interest to those application developers who are not familiar with Yocto.
  • GDP Master wiki page, with instructions to build from scratch GDP with support to a wider range of target boards if you have Yocto knowledge.
  • GDP bug tracking system for those of you who want to provide feedback about this release. The GDP Delivery Team love bug reports!
  • GDP roadmap if you are interested in the coming GDP 11 release.

We very much appreciate any and all testing of the GDP 11 RC1 as it helps us create a better development platform for those interested in producing automotive software.


During the last few weeks, the GDP project has moved rapidly. Summer is the perfect time to work quietly in bringing new improvements since most of you are on vacation. These are the GDP highlights.

GDP 11 Beta is coming


Tomorrow Wednesday August 3rd, GDP 11 beta will be released.

And what about GDP 10?


After a couple of weeks of discussion, the GENIVI community took the decision  per consensus to skip GDP 10 and go directly for GDP 11, This is a similar situation to that which took place some months ago with GDP-ivi8, which was skipped in favour of GDP-ivi9. So nothing new under the sun.  The main reason for this decision has been to open the possibility to provide the latest versions of every GENIVI component shipped in a stable release with ports to several target boards to developers and companies on time for the GENIVI 15th AMM.

 

The specific timeline for GDP 11 is currently under discussion. Feel free to participate, especially if you are willing to contribute software to GDP or intend to use it for demoing your latest application for example, at the GENIVI 15th AMM in October.


What is new in GDP 11 Beta?


This Beta release will bring the latest stable software shipped by the Yocto project (v2.1) together with the latest GENIVI software components (meta-ivi MIRANDA v0.1). The only delivered target will be QEMU. RC1 will bring ports to a variety of target boards. The GDP Delivery Team believes GDP 11 Beta will be the ideal starting point for automotive developers interested in either testing the latest GENIVI software or developing the next generation of automotive components and applications, using as based GENIVI compliant middleware.


GDP is all over the globe


On June 2nd, GDP was presented at the OpenExpoES, in Madrid, Spain. On July 13th, GDP was introduced at the Automotive Linux Summit that took place in parallel with LinuxCon Asia in Tokyo, Japan. On October 12th there will be a talk about GDP, with the title "Open Source For Automotive In The Open Becomes Real: GENIVI Development Platform" at ELCE that takes place in Berlin, DE. Obviously the GDP will also be present in several talks, demos and training sessions at the GENIVI 15th AMM, in Burlingame, CA, US from Oct 18th to 21st.

 

What's new in GDP Master?


With the new rolling model, the GDP Delivery Team is able to move faster so lots of updates has landed in GDP Master. Impatient developers, addicted to the latest and greatest software can see now in GDP a solid option to develop Open Source automotive software. meta-ivi 10 and 10.0.1 later, together with Yocto 2.0 and Qt 5.5.1 landed to GDP a few weeks ago although lately those fundamental pieces has been updated to meta-ivi M.0.1, Yocto 2.1 and Qt 5.6.

 

Updates in the bluetooth stack, wayland-ivi-extension, dlt daemon among many others have already landed to GDP, together with updates in weston, mesa and new software like Fuel Stop Advisor, conman-client or openssh-sftp-server, for instance. Qualcomm Dragonboard 410c is now supported in GDP Master. Due to these major updates and the fact that the Delivery Team is preparing GDP 11 Beta release, ports to other boards might not be fully working. This is a temporary state since right after the coming release, their effort will concentrate on ensuring those ports works.


So stay tuned for the coming release of GDP 11 Beta and test the latest Open Source software for automotive. Those closer to GDP and GENIVI, might prefer to follow GDP Master, but do not fall asleep, GDP is moving faster than a Pokemon hunter.

The GENIVI Development Platform Delivery Team is happy to announce the first pre-release of GDP 11, the new version of the platform for automotive Open Source developers.

 

This beta release represents a major update for most upstream software in GDP compared to the previous release GDP-ivi9. Yocto has been updated from version 1.8 (fido) to the latest stable Yocto release, 2.1 (Krogoth). Qt moved from version 5.4.2 to Qt 5.6.0. Several relevant updates on key automotive components are also included. Some of those come with meta-ivi 11. GDP for the very first time ships a development version of meta-ivi so professionals interested in some of the components that follow GENIVI specifications can test them, helping GENIVI Expert Groups to improve them. GDP also ships some other updated automotive specific components beyond meta-ivi like NAVIT, or tools requested by users. Last but not least, GDP 11 beta includes Fuel Stop Adviser (FSA), a new demo application.

 

You can download the GDP 11 Beta port for QEMU target only from the GDP Download page. Ports to different target boards  will be delivered in the next pre-release. The final GDP 11 release is scheduled for mid September, around the same dates that the new release of meta-ivi 11 is expected, on time for the GENIVI 15th AMM.

 

To make GDP great, testing is welcome. Feel free to download GDP 11 beta or build it from scratch from Master. Then tell us what is suitable for improvements or file a bug report.

 

Relevant links:

  • GDP Download page: download the GDP 11 Beta binaries, metadata and artifacts
  • GDP 11 feature page: description of what comes with this pre-release.
  • GDP 11 beta port to QEMU: instructions about how to build/download and run GDP 11 beta for QEMU.
  • GDP Releases: links to other resources related with GDP releases.
  • Yocto 2.1 release notes and software packages included: information about upstream code and recipies that are part of this pre-release.

About GENIVI Alliance

GENIVI® is a nonprofit industry alliance committed to driving the broad adoption of specified, open source, In-Vehicle Infotainment (IVI) software. The alliance develops an open standard for aligning automotive and consumer infotainment cycles. Our work results in shortened development cycles, faster time to market, and reduced costs for companies developing IVI software. For more information, check GENIVI website.

The past few weeks the GDP delivery team together with some key contributors, have been working on a not very visible but still important change. The GDP project has created the basis for turning the GDP release based delivery model to a "rolling" one. My colleagues will provide in a coming post the technical details behind this change. I want to provide a higher level view of what is happening and why.

Some background

 

GDP was born as a "demo" project. The main goal was to provide a platform to show the software components for automotive that the different GENIVI Expert Groups were developing. This was done through a delivery model focused on publishing a stable and easy to consume version of the project every few months, a major release.

 

Strictly speaking, the GDP is a derivative. It is based on poky and uses Yocto tools to "create" the Linux based platform, adding the different components developed by the GENIVI Alliance together with upstream software. For the defined purpose, the release centric model works fine, especially if you concentrate your effort in very specific areas of the software stack with a small number of dependencies on the other areas, and a limited number of contributions and environments where the system should work. During 2016, GDP has grown significantly. We have more software, more contributors, more components and more target boards to take care of. Although the above model has not been not challenged yet, it was just a matter of time. As explained in two previous posts[1][2], the GDP is moving from being a Demo to a Development Platform. Changing the mission means changing the goals and the target group, which implies the need to adjust the deliverable to meet the new expectations.

 

So, right after the 14th AMM, the Delivery Team decided to change the delivery model to better meet the new mission, providing developers the newest possible software with an increasing quality threshold. At the same time, in order to increase the number of contributors, the GDP needs to provide a new solid platform every once in a while. That should be done through a solid release.

What is a rolling delivery model?

The key idea behind a modern delivery release model is to ensure that the transition from one stable release to the next one takes an affordable effort. I will display an example to picture the idea.

Problem statement

 

Imagine an organization that publishes one release per year. Let's assume that a particular release included 100 patches developed by employees and, during the lifetime of the release (1 year too), another 100 patches were added to the product as bug fixes and updates. At the end of the release lifetime, the product includes 200 patches that define the value the product provides to customers and users.

 

Either for technical or business reasons, a year later it is time to upgrade. Our organization has to create a new Linux based system with newer upstream code and they have to integrate the patches from the previous release plus the updates and bug fixes developed for the coming release.

 

After a simplification process done by engineers, the number of patches needed to be integrated in this newer base system is reduced to 150. The organization also wants to add to this new release another 100 patches that represent the new features they have been developing during the last year for this new version. The delivery team now has to integrate 250 patches in the new base system, 150 of them coming from the previous release. One might think that the effort required to do this is 2.5 times the effort invested in the previous release. Maybe you think that the effort is not so high since some of the patches have been developed thinking about the new base system. There are many other considerations like this one that might affect the initial estimation. This example is obviously a simplification.

 

However any experienced release manager will tell you that moving patches integrated in an older system base onto a newer one (forward-porting) requires additional effort, beyond a linear relation with the number of patches. Forward-porting is the "road to hell". Iterate this example a few times and you will understand why there are so many organizations out there that have as many people focusing on delivery as they have in development. They migrated to Linux base system keeping the traditional delivery model they had while working with closed source software.

Possible solutions

 

One of the paths to improve the situation is upstreaming those changes that affect generic components. Some companies also upstream their new features early in their development process, generally looking for wider testing, or after they have been released to customers, to increase adoption and reduce future maintenance effort. This is definitely a must do.

 

From the delivery perspective, the most popular way to tackle the problem though is reducing the release cycle, so the number of patches to forward-port in each release is smaller. The development time and the maintenance cycles are also smaller. The same applies to the complexity of the forward-porting activities. "Jumping" from one release to the next one is easier to do. Add automation of repetitive tasks to this recipe and you feel you have a win.... for some time.

 

The journey through the "road to hell" becomes more comfortable, but our organization is still getting burned, even in the case that our customers and ourselves can digest releasing frequently. We all know how expensive and stressful a release might become.

 

The most suitable option to achieve sustainability while scaling up the amount of software an organization can manage without releasing more often than your market can digest is to change your delivery model. Rolling delivery models are a serious attempt to solve this problem, putting integration as the central element instead of the software itself.

 

This model is not new. Gentoo has been doing it forever, but it was Arch Linux who implemented it in a way that immediately attracted the attention of thousands of developers. Still it was a model with no hope beyond hardcore Linux developers. openSUSE brought this model to a new level by implementing a process whose output was stable enough for a much wider audience, and compatible with the release of a more stable and a commercial releases. Nowadays there are other interesting examples out there that commercial organizations can learn from.

What is a rolling model?

 

It is still hard to define but essentially it is a process in which ideally you have one continuous integration (CI) pipeline as the one and only entry point for the software you plan to ship. Releases then become snapshots of all or part of the software already integrated after going through a specific stabilization, deployment and release process.

 

So ideally, if you release a portfolio, you integrate only once, reducing significantly the costs of having different engineers working on different versions of the same software and forward-porting, among other benefits. A rolling delivery model is then a lot more than a continuous integration chain, although that is the key point. Please have in mind that this is an oversimplification. This description doesn't go into detail on other key aspects like maintenance cycles, how upstreaming affects the process, strategies towards updating the released products, etc.

 

A transformation process that takes an organization from a release centric model to a rolling one is about doing less and doing it faster, so less people can handle more software with less pain, allowing more people to concentrate in creating value, developing new and better software instead of just shipping it

Back to GENIVI

 

Moving from a release centric to a rolling model is hard work. Frequently it is easier to start all over again. Since the GDP is still a relatively small project, we can afford going through the transformation process step by step.

 

The first stage has been creating that single integration chain and treating GDP-ivi9, our latest release, and those that follow it, as a deliverable of what we call today Master. Ideally, no single patch will be added directly to the release branches. They should come from Master. That way, we reduce (ideally to zero) the effort of forward-porting of patches while putting in the hands of our contributors the latest software on a regular basis.

 

To do so, we are in the process of adapting our simple processes and CI system to the new model, GDP repository structure, the wiki contents, the task management structures, several key policies, our communication around the project...

 

The GDP will face a very interesting challenge since this model needs to be proven successful for a derivative. If we are able to move fast enough, it will come the time in which we will need to decide if GDP keeps being a derivative or it becomes upstream, that is, either GDP limits the delivery speed based on the Poky release cycle, or we work upstream with the Yocto project to increase our delivery speed.  That is a good problem to have, isn't it?

 

If (almost) everything goes right, after adding a few needed services in GENIVI's infrastructure and ensuring the updated software is in compliance with selected verification criteria, the same number of people will be able to manage and deliver more software. And once the new processes become more stable, automation will not just increase efficiency, it will boost the project by allowing GENIVI to achieve goals that only big organizations with large delivery teams can do. This is the kind of transformation that takes time to consolidate, but has a huge impact. Based on my experience, I believe that if GENIVI is able to sustain this effort and keep a clear direction the next couple of years, the benefits of moving towards a rolling model will be noticeable even outside the industry.

With this blog post, the GDP Project reaches a relevant milestone. We have turned our previous release based delivery model into a rolling one by creating a central pipeline where GDP is continuously being integrated. Out of this integration point, the GDP Delivery Team can release different deliverables targeting different audiences. Currently there are two main deliverables, GDP Master, targeting those GDP contributors and Power Users who need the latest available software, and Major releases like GDP-ivi9, which targets GDP users who want to consume more stable software in the form of images ported to specific target boards.

Why did GDP switched from a traditional delivery model to a more flexible one?

Some of the main reasons are:

  • Makes it easier for interested parties to know where the work / bleeding edge of GDP is being conducted, previously we've received feedback stating the branch structure / naming schema was confusing, this should ease that problem.
  • Having Master not be a strictly defined 'release' or 'golden' branch also allows more flexibility for the project, allowing master to develop whilst having a stable maintenance branch for such purposes.
  • genivi-dev-platform repository started by having branches per target, that during release cycles could end up out of sync due to focus being applied to a specific target (mainly qemu, for non-bsp requirements). It was intended that the 'master' qemu branch could be used to rebase/merge all common changes across all target branches, but this proved more difficult in practice and quickly got un-manageable even for simple changes (e.g. .gitmodules + conf file conflicts).
  • Moving to a singular branch for all targets also comes with its own intricacies  (more explicit scripting, the assurance of common commits etc) however managing contributions and building images from scratch is more efficient.
  • Merging the git history of ~5 targets into a single branch in a sane way was not possible, so the qemu branch was taken as a base. Obviously the respective histories of each target branch in GDP is important, so the branches have been archived as tags.

And how does this new model works?

The more important policies that rules the submission and management processes are described in the GDP Management wiki page. The main goal of these policies is to create a system in which it possible to keep a constantly developing master branch, as well as providing a platform (branch) that acts as a stable snapshot of a release and as such is maintained for a given period. The policies will be applied by the maintainers, but it is important that users (whether that be contributors etc) follow the guidelines where possible, as this will ensure that GDP is workable for all parties. If a contributor is aiming to upstream a new package into GDP (directly into meta-genivi-dev or via an external layer) then it is expected to be compatible with the current genivi baseline / yocto baseline component versions available in master. This ensures that the GDP continues to move forward. Generally it is expected that any patch / PR to either repository is expected to pass the go.cd integration pipelines to ensure the system is buildable. go.cd/github has been configured to report the status of the relevant pipelines in the PR GUI.

That said this is only used as an initial check, and still requires standard code review. The CI is not bulletproof, build-failures are assessed to check if the PR was the root-cause and acted upon accordingly. Please note: as it stands GDP due to the nature of being defined essentially by two repositories, has well documented / discussed PR scenarios in which PR's to both repositories have to be tested in the same integration test. There is currently no mechanism in place to test this scenario and as such has to be dealt with manually for now. GDP now makes use of selective git submodules to generate the corresponding yocto layers based on the target being built, including meta-genivi-dev which also follows the master branch policy. The remote head of the repo is set to the master branch, i.e master is the default branch. And tags will still be used for snapshots of releases.

As you can see there is still a long way to go towards having a truly continuous delivery model through a rolling release but some fundamental steps has been taken. Obviously it is still possible to contribute to GDP via patches to genivi-projects@lists.genivi.org, as stated in the updated GENIVI Contribution policy.

GDP-ivi9 gets into maintenance mode

One of the consequences of adopting this new model is that GDP-ivi9, our latest release, gets into the maintenance cycle until the next major release is published, which is expected within this year. There are currently maintenance branches 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:

The intructions to build and run GDP-ivi9 has been updated to reflect these changes and new policies has been defined for maintenance.

Other areas of the project that has been improved as a consequence of the new model

Wiki

The fact that we have now two deliverables instead of one targetting different audiences have an impact in the way our contents are structured. Now there is one central page for each one of them from which Master and major release users can get all the information required to either run or download and boot GDP. For those who want to consume the latest and greatest, GDP Master is their page. Those more interested in a more conservative and easy to consume approach should go to GDP Releases wiki page. The reference page to download images and metadata remains unchanged.

As usual with key changes, there is still some work to be done in order to update contents in several pages, check links, titles, references to Master, update diagrams, etc. Not all this work is completed but most of the relevant updates are done by now. Feel free to point us to potential improvements.

Task management

Since Master is the central integration point and it is a continuous effort, we have re-structured the GDP Epics to reflect that most of the work is done now in Master. We have extended the usage of the JIRA capabilities related with Releases (FixedVersion), simplified the interfaces to create/update tasks, improve the integration between GitHub and JIRA/Confluence and other actions that will make our everyday work a little more efficient and easy to follow.

The main GDP Delivery Epics are now:

  • GDP-257 In Progress where all the tasks related with Master are being tracked.
  • GDP-23 Done where the delivery team collects all the tasks related with the potential next release. At this point it is undetermined if we will skip GDP 10 (based on poky 2.0 and meta-ivi 10) and jump directly to GDP 11. A new epic would be created in that case.
  • GDP-8 - GDP-ivi9 In Progress where the only active task is GDP-259 Done to track the main actions taken to maintain the current release.

 

In summary, GDP has adapted the traditional GENIVI delivery model to a more flexible and modern one, executing actions at different level as consequence of the changes introduced

 

GDP Delivery Team

Hi all,

I'm moving to a different project, and Robert Marshall will be doing work in my place.

When I joined this project, the GDP was in a bit of a state:

  • Getting started was an exercise in manual frustration - checking out repos at specific commits, manually setting up environment variables... Plenty of space for things to go wrong, and taking longer than it needed to.
  • So much was happening behind closed doors. Discussion and decisions were happening behind closed doors, people only knew what was happening in the GDP when release announcements happened.
  • Many parts of it didn't work, or had missing features.
    • The lifecycle subsystem wasn't integrated fully.
    • The location-based services (fuel stop advisor, etc.) weren't integrated fully.
    • The GDP HMI was hard-coded and temperamental about being started.

Six months later, and there's been a definite improvement in the GDP (even excluding that it's gone from use with meta-ivi 7 to meta-ivi 9, with 10 on the horizon):

  • We're all working out in the open, being active on the genivi-projects mailing list and on the #automotive IRC channel.
  • We're releasing images people can download and run!
  • Getting started has been hugely streamlined (thanks Gunnar!) with all the required repos being submodules within a genivi-dev-platform repo.
  • The HMI is slightly less temperamental about being started.
  • We have lots of Contributors! Changhyeok Bae (who's now a maintainer), Leon Anavi, Jeremiah Foster and Gunnar Andersson to name a few.

Unfortunately, the parts missing features generally are still missing features, but there's interesting things happening in the future:

  • We're working with the Location-based services maintainers to get the FSA integrated and working.
  • Everybody's aware of the GDP HMI's problems, and are interested in replacing it.

Overall, I'm pleased with what we've accomplished so far, and no small part of it was due to Agustin's commitment to transforming the GDP into a healthy, open-source project.

This isn't a goodbye, I'll be lurking in the IRC channel and mailing lists for a while. I'm sure you'll all be happy in Robert Marshall's capable hands, he's an experienced developer and the only thing I can fault him in is his favourite text editor :)

Thanks,

Jonathan

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.


Intel Minnowboard joins the GDP-ivi9 family.

In terms of delivery, one of the biggest challenges in Linux based systems is to provide a simple way to use and test middleware. GDP targets that problem for automotive, and to do so, providing images for common boards becomes a requirement to succeed. Back in April 19th, GENIVI Alliance released a new version of its Development Platform, GDP-ivi9, including ports to Renesas Porter and Raspberry Pi 2, together with QEMU.

Today GENIVI Alliance is happy to announce one more port. Intel Minnowboard Max joins the GDP-ivi9 family as officially supported board. Feel free to download the new port as well as the other ones through our Download page. Run the new port or build it from scratch following the detailed instructions published as part of this release.

But this is not the only news around GDP.

GDP, from Demo to Development Platform

During GENIVI 14th All Members Meeting, that took place in Paris from April 26th to 29th, Steve Crumb, GENIVI GEO, announced during his keynote that GENIVI Demo Platform would be called from that moment on GENIVI Development Platform, which better reflects the new objectives and spirit of the project, which is to focus on developers, bringing innovation into GENIVI to spread it across the automotive industry. 

GDP delivery team is in the process of reflecting this change throughout the documentation and code. Feel free to report any inconsistency you might detect.

GDP moves to Github

Following the rest of the GENIVI Alliance projects, GDP is in the process of moving from the former git infrastructure to GitHub. The following quotes from key people at GENIVI explain the goal of this move:

 

“Thousands of developers in many industries have made GitHub their home for productive open source software development. The fact that GENIVI is establishing its “hub” in this broad community is yet another step toward our goal of having a far-reaching and productive community of developers and adopters of open source software for the connected vehicle.” - Steve Crumb, GENIVI Executive Director.

 

"The move to GitHub will allow GENIVI to have greater control over its infrastructure and software development process. This in turn will hopefully allow quicker response to infrastructure issues, and a lower barrier to contribution. One simple example is the fact that corporate firewalls find the git protocol, and ssh for that matter, problematic. GitHub has excellent support for https using strong encryption via certificates which means corporate firewalls can remain in place without any workarounds."- Jeremiah Foster, GENIVI Community Manager

 

The two main repositories related with GDP are the following:

  1. meta-genivi-dev
  2. genivi-dev-platform

The project will keep using JIRA as bug tracker and task management tool and Confluence as wiki. Feel free to submit your patches through GitHub, fork the current repos, review pull requests.....  contributions are welcome. GDP is an Open Source project, done in the open.

 

About GENIVI Alliance

GENIVI® is a nonprofit industry alliance committed to driving the broad adoption of specified, open source, In-Vehicle Infotainment (IVI) software. The alliance develops an open standard for aligning automotive and consumer infotainment cycles. Our work results in shortened development cycles, faster time to market, and reduced costs for companies developing IVI software. For more information, check GENIVI website.

The GENIVI Alliance is happy to announce the release of the new version of its demo platform, GDP-ivi9.

GDP is the Open Source demo platform including the middleware software components developed by the GENIVI Alliance. GDP-ivi9 targets software engineers interested in the development of FLOSS for automotive.

You can download this new release from the GDP Download page.

GDP-ivi9 is based on  Poky 1.8.1 'Fido' and meta-ivi 9.0.1, bringing weston/wayland and wayland-ivi-extension 1.9, Qt 5.4.2 and many bug fixes and security updates. This version of GDP targets, in addition to QEMU, the following boards:

Some other target boards might be delivered in the coming weeks. Follow the instructions linked on  GDP-ivi9 feature page to download and run this new version of the GENIVI Demo Platform or to build it yourself from scratch.

The GDP delivery team welcome contributions, following common practices among Open Source software communities. If you are interested in building your application on top of GDP-ivi9 or porting it for a new board, feel free to contact us though our open channels.

Relevant links:

The GDP delivery team would like to thank the GENIVI Alliance community for the effort put on this release cycle together with those upstream projects and maintainers who have made GDP-ivi9 possible.

 

 

About GENIVI Alliance

GENIVI® is a nonprofit industry alliance committed to driving the broad adoption of specified, open source, In-Vehicle Infotainment (IVI) software. The alliance develops an open standard for aligning automotive and consumer infotainment cycles. Our work results in shortened development cycles, faster time to market, and reduced costs for companies developing IVI software. For more information, check GENIVI website.

GENIVI Alliance is happy to announce the availability of the first release candidate of the GENIVI Demo Platform GDP-ivi 9. You can download it from the GDP Download page. Follow the instructions to run this new version or to build it yourself from scratch.

 

GDP is the Open Source demo platform developed by GENIVI and its members for automotive. GDP targets software engineers interested in the development of FLOSS for this sector. Like the previous beta release, this first release candidate is based on GENIVI Baseline 9.0.1. Wayland, weston and wayland-ivi-extension have been updated to 1.9.0. There have been non-backwards-compatible API changes in wayland-ivi-extension.

 

The GDP delivery team welcome contributions, especially by testing this release candidate and providing bug reports, following common practices among Open Source software communities. If you are interested in building your application on top of GDP, feel free to contact us though our open channels.

Relevant links:

 

During the coming weeks, the GDP Delivery Team, together with the GENIVI community, will focus their efforts in delivering GDP images for the different target boards: Renesas Porter/Silk, Intel Minnowboard and Raspberry Pi 2. If you are interested in porting to other boards or further details about the upcoming GDP releases, please check the Roadmap page.

 

About GENIVI Alliance

GENIVI® is a nonprofit industry alliance committed to driving the broad adoption of specified, open source, In-Vehicle Infotainment (IVI) software. The alliance develops an open standard for aligning automotive and consumer infotainment cycles. Our work results in shortened development cycles, faster time to market, and reduced costs for companies developing IVI software. For more information, check GENIVI website.

The GENIVI Demo Platform now supports the GENIVI Audio Manager Monitor. The GENIVI Audio Manager Monitor provides an insight of the behavior of the GENIVI Audio Manager. Its goal is to explain the mechanisms of the GENIVI audio system and to help developers to integrate their audio sources. The GENIVI Audio Manager Monitor works with the GENIVI Demo Platform but also on a Ubuntu PC.

 

Note: This article was published by By Frederic.Bourcier on April 27th, 2015 in GENIVI's former infrastructure.

The GENIVI Demo platform updated its HMI launcher. The new HMI launcher brings a new UI but not only.

It was specifically developed to leverage several aspects of the GENIVI design now implemented in the GENIVI Demo Platform. The HMI launcher manages the transition of focus between applications, making use of the GENIVI Layer Manager. It also uses DLT, and it is interfaced with the GENIVI Lifecycle components to start and stop demo applications.

Best Regards,

The GENIVI Baseline Integration Team.

 

Note: This article was published by By Frederic.Bourcier on April 10th, 2015 in GENIVI's former infrastructure.