-
Notifications
You must be signed in to change notification settings - Fork 16
ODPi Infrastrucutre
- Technical Working Group mailing list: https://lists.odpi.org/mailman3/lists/odpi-technical.lists.odpi.org/
- Continuous Integration: http://build.odpi.org:8080
- Package Repository: http://repo.odpi.org
- YUM repo file URL: http://repo.odpi.org/repository/ODP/centos7/2.x/BUILDS/0.9.0.1-55/odpbn.repo
####Effective branching workflow and naming schema
- each cloned ODPi repo should have a set of odpi-specific branches, prefixed with "odpi-", e.g. for Hadoop repo it will be odpi-branch-2.7.1 to correspond to branch-2.7.1 (needless to say, cloned repos will contain the original set of the branches from the project-proper)
- odpi-* branches will carry on the context of a branch from project-proper + whatever modifications to be applied and weren't up-streamed
- ODPi stack BOM should be pointing to either the odpi-release or a particular odpi- dev. branches and be creating the binary artifacts from there. A component build can either use direct git hash to produce the binaries, or utilize the GH archive generating facility. The latter is much faster
- during a release, odpi-release-X.Y.Z branch will created to carry on for all branding modifications as needed
- bringing in the changes should be done via standard PRs into odpi-* specific branches
- keeping the odpi-* specific branches up with their upstream counterparts needs to happen at regular intervals for actively developed branches, and on a need-to-do basis for released ones.
As a quick example: odpi/bigtop odpi-master branch refers to odpi/hadoop odpi-branch-2.7.1 branch, that has all version modifications for ODPi version of Hadoop component (right now only version string changes).
A suggestion has been made to include ODPi stack version number into the branch name to distinguish different release train. I would like to postpone on implementing such a complication, until we see that is really necessary. See https://jira.odpi.org/browse/ODPI-7 for more details
odpi-specific branches need to stop on top of the corresponding upstream branches, when seems reasonable or required. On the other hand, changes would need to be made to these odpi-specific branches. The following work-flow outlines the process. Recommended way to sync-up odpi-specific branch (ie odpi-master) with its upstream counterpart (master)
- sync up master of the odpi-specific repo with its upstream origin. It could be done directly without involving GH PR. assuming you have two remotes origin for odpi-specific GH repo; and public for its upstream
git fetch origin
git fetch public
git checkout -b master public/master
git push origin HEAD:master
- fork and create your own clone of odpi-specific repo (yours). Then in it
git checkout -b hotfix-branch odpi-master
# make and commit you changes
git push yours HEAD:hotfix-branch
# Create PR to the *odpi-master* from the new *hotfix-branch* as usual with GH flow.
####Package naming schema
The native Linux package names need to communicate the following info:
- name of the component
- version of the component
- belonging to an ODPi stack
- version of the reference implementation release (under discussion)
This translates into a package name, which in case of Hadoop HDFS will look like the following:
hadoop-hdfs-2.7.1+odpi_1.0-1.noarch.rpm
####Maven artifacts versioning
Programming artifacts deployed into and used from ODPi public Maven repository should convey the following:
- version of the artifact, reflecting the version of core component
- optional number of added modifications or Patch Level (PL>0)
- the artifact belonging to ODPi stack
In case of Hadoop HDFS, the jar file will look like
hadoop-hdfs-2.7.1.PL-odpi.jar
See https://jira.odpi.org/browse/ODPI-3 for more details
This work is licensed under a Creative Commons Attribution 4.0 International License