See for the official Zabbix site.

Docs/github project

Jump to: navigation, search


This is an attempt to maintain community patches for the latest minor releases on Github. The whole release tarball is checked in, so that the whole code base can be targeted.

For the ease of consumers, static patch files shall be exported and provided somewhere. Generally, contributors are responsible for keeping their stuff updated, but should not feel obligated to maintain it for versions they don't use yet/anymore. Useful commit messages are a must though!

Schematic repo layout

 / zabbix-2.4  <- Work on this branch for 2.4!
 / zabbix-2.4.2
 / zabbix-2.4.3
-+ zabbix-2.2  <- Work on this branch for 2.2!
 \ zabbix-2.2.7
 \ zabbix-2.2.8
 \ zabbix-2.0  <- Work on this branch for 2.0!
 \ zabbix-2.0.13
 \ zabbix-2.0.14

See below for the reasoning!

New release workflow

All branches are created on the working branches (zabbix-2.2, zabbix-2.4). Whenever a new point release is published, it is checked in as a sibling to the working branch (for instance as zabbix-2.2.8).

 $ wget .../zabbix-2.2.8.tar.gz
 $ tar -xf zabbix-2.2.8.tar.gz
 $ rm zabbix-2.2.8.tar.gz
 $ git add zabbix-2.2.8
 $ git commit
   <enter commit message, for example: add vanilla upstream 2.2.8 source tree>
 $ git push

The branch is then merged into the respective working branch, as we always want to support the latest minor releases only. Depending on the upstream changes, this may cause merge conflicts on one or more branches. These conflicts should be resolved, otherwise the branch in question does not provide a useable patch.

what if some working branch is not merged into (for whatever reasons - massive conflicts etc) - how would that be detected/displayed ? --Richlv (talk) 07:05, 12 December 2014 (EET)

Branch naming convention

The idea is to have a branch for every single ZBX/ZBXNEXT issue respectively. We shall attempt to make non-conflicting changes, wherever possible. In cases where this is not possible, a new branch can be created to span more than one issue. The branch must be named to reflect this. If multiple approaches or implementations exist for one issue, try to name them after the original author or something else that makes them easy to distinguish.

  • zabbix-2.2-ZBXNEXT-410-filter-events-page
  • zabbix-2.0-ZBXNEXT-410-filter-events-page
are the above suggested branch names when there are multiple implementations or would one always add descriptive name after the issue number ? --Richlv (talk) 04:54, 12 December 2014 (EET)

Issue workflow

Changes should be committed to the respective branch on Github and the Github URL should be posted on the Zabbix issue tracker. Upon changes, the author should leave a comment on the issue about the latest development on the branch in question. It should not be necessary to attach patches to the issue. If attached however, please name the patch according to the Git commit it reflects.

it might be useful to attach patches anyway for the Zabbix developers' convenience --Richlv (talk) 04:56, 12 December 2014 (EET)