Motivation for GDP Master
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@github] 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 ultimately it should prove beneficial to both users and maintainers.
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.
Projected audience and users of the GDP Master
You should be using master if you wish to be part of the development cycle of the GDP, or want the most recent versions of the underlying components provided by poky / meta-ivi etc.
The Patch Submission Process
What are the main goals of these policies? Who will apply them? Why are they important?
The main goal of the 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.
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.
Of course it is still possible to contribute to GDP via patches to firstname.lastname@example.org
General documentation re contributing to Genivi can be found HERE
Specific GDP related contribution policies can be found HERE
Tasks done to get here
Summary of the tasks done to get to this point
I think I've already covered this point in the starting motivation paragraph, feel free to rearrange content
Again already linked to meta-genivi and genivi-dev in various places, might be beneficial to link to poky / meta-ivi?
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 donwload 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 a 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 potential improvements.
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 ussage 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 Epic are now:
- - GDP-257Getting issue details... STATUS where all the tasks related with Master are being tracked.
- - GDP-23Getting issue details... STATUS where the delivery team collects all the tasks related with the potential next release. At this point is undetermined if we will skip it and jump directly to GDP 11. A new epic would be created in such case.
- - GDP-8Getting issue details... STATUS where the only active task is - GDP-259Getting issue details... STATUS to track the main actions taken to maintain the current release.
when does the maintenance period start and finish (when next release. roadmap is currently under discussion. Maximum, end of this year).
This needs to be defined, I've currently stated in the policy section that we aim to keep the current 'release' branch in maintenance mode until the 'next' final release is declared from master.
As it stands, that's roughly defined by upgrades through poky/ivi versions. Once the next release is declared, the gdp-ivi9 branch will still be available, but will be retired from maintenance mode
Where to find GDP Master
The wiki page describing the GDP Master is here.
GDP makes use of git submodules to generate the corresponding yocto layers, 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.