-
Notifications
You must be signed in to change notification settings - Fork 0
Home
This is Intevation's repo of https://github.com/certtools/intelmq to help the development of IntelMQ and prepare (public) releases for our customers.
Our aim is to bring all changes upstream if possible.
It is strongly preferred to create issues upstream. Only create issues here if they are very specific to Intevation branches.
master should be in sync with upstream certtools/master, whoever sees a difference fast-forwards.
Base your development branches on master.
release should be releasable. So merge in all dev branches that have been tested in integrated before and are ready for release. Any changes from master that are potentially unstable should be disabled or left out. For hints on merging see below.
integrated should integrate all developments (all development branches) on a regular basis (daily if there is progress) and also current from master.
Call your development branch dev-XYZ.
Fork it from master (strongly encouraged) or if necessary from another dev-branch,
merge to integrated often (each time you have a development step done
that will not crash others parts). It is in the responsibility of the dev-branch owner to keep
integrated in good state. When the development was tested: issue a pull request to release and (if appropriate) to certtools/master.
If the changes are relevant to upstream, commit them to ubuntu.
Pull Requests can be based on this branch.
If the changes are not (yet) relevant to upstream or must not go upstream,
commit them to deb-packaging.
Regularly mergeubuntu into deb-packaging.
This tactic is currently (11/2016) not used. Releases ar build from the integrated branch
After successfully testing feature in the integrated branch they should be merged into the release branch. It is important to merge the tested version of the relevant dev branches. So basically two information are needed: which dev branches to merge and what change set.
One can use git log --merges integrated to list all merge commits in the integrated branch. Lookout for merges into the integrated branch, newer than the last release. Then look at the Merge: header, it shows the parent ids of the merge, the right one is the one that was merged in, so it is the revision, that we might want to merge into release.
git checkout release
git log --merges integrated
# Shows i.a.:
#
# commit d49e2debb7cf4e4e0670bad97a980b2e0f2e42b8
# Merge: f82cbb5 b0214bb
# Author: Sascha Wilde <[email protected]>
# Date: Tue Jul 12 16:06:46 2016 +0200
#
# Merge branch 'certbund-contact' into integrated
#
# We decide to merge it into release, too:
git merge -m ' Merge commit 'certbund-contact' b0214bb into release' b0214bb