Zabbix uses Git with Bitbucket for version control - https://git.zabbix.com/
user.emailmust be set to values matching user account in JIRA.
push.defaultmust be "simple".
core.eolmust be either unset or "native".
feature/*from an original branch, e.g.
and conflicts resolved.
before testing and code review may happen.
It is important to merge the feature branch into the source by merge commit even if a fast-forward merge is possible.
Periodic merging from the source branch and merging from the source branch prior to the testing must happen because:
a) it is better to discover and easier to solve conflicts as soon as possible and in smaller batches;
b) when testing, it is not worth wasting time on a development branch which is outdated, compared to the current source branch;
c) changes in the source branch may affect the functionality that is tested in the development branch
release/4.0) must be integrated into other branches (e.g.
release/4.2) by cherry-picking
make csscommand should be called, and updated
.cssfiles also should be added to commit.
.cssfiles should be regenerated together with each merge commit, where any
.scssfile were modified.
Where ISSUES is a list of comma-separated issues, COMPONENTS is a fixed-size list of components affected by this commit (see #Components).
.gitignorein Zabbix root folder contains all common directory and file names that must be ignored by Git (such as
.gitattributesin Zabbix root folder sets default handling of line endings as
text=auto !eol. This is roughly equivalent to
svn:eol-style=nativeproperty in Subversion unless Git's configuration parameter
core.eolis set to values other than
nativeand doesn't match platform's convention (it's ok if
.gitattributesalso defines files that should be treated as binary:
.gitignorefile into an empty directory to work around this limitation:
Files that have been edited with Inkscape may contain sensitive information (
inkscape:export-filename attribute may contain full path exposing directory structure, username etc - see Inkscape bugreport) or useless information in attributes
inkscape:export-ydpi. These attributes should be removed before committing svg files.
In the Zabbix repository, there's
misc/images/strip_inkscape_attributes.xslt file that allows to easily strip those attributes.
Zabbix uses Jira for issue tracking - https://support.zabbix.com/.
"Fix Version/s"field is used for two purposes:
'highly recommended' to watch the issue. That would allow the developer to respond to comments or reopening of the issue by users later.
"Fix Version/s"field to appropriate values as soon as possible - it reduces the possibility of some issue being neglected and makes planning for releases easier.
Fixed in development branch [feature/ZBX-1234-4.2|https://git.zabbix.com/projects/ZBX/repos/zabbix/pull-requests/36/overview]
'sub-issue'. For each sub-issue a separate comment is added and is edited when working with it.
An example of sub-issue dialog:
(1) [F] During the fix we broke feature X. This is very sad. [~developer] Oops, sorry. RESOLVED in a1b2c3d [~tester] Now feature Y is broken. See, if we do A, then hide B by clicking on C, we are left with D being on top of E. Considering that F should not be there either, this is not good. [~developer] Ouch, fixed A handling in B. RESOLVED in 2a3b4cd, 1b2c3de [~tester] CLOSED
An example of a sub-issue dialog with 2 testers:
** Checking for changed translation strings **
An easy way to check for translation string changes is to run in the directory. Then a simple script may be used:
This defaults to checking the
sk locale, but you can manually choose any other. It lists changed
msgstr lines (thus also showing whether removed strings were translated in this particular locale).
After checking these changes should be reverted, as this all happens before testing which is likely to cause additional changes.
** What should be documented where **
The developer should try to think about all the possible implications of a change - what pages change, which labels change, should any screenshots be updated.
Many changes also have to be noted in the "what's new" and "upgrade notes" pages. When deciding what should be documented where, this example might help:
For example, in 4.2.0 Zabbix sender started using all addresses found in ServerActive parameter. This is clearly an improvement over previous versions and should be put in "What's new". But this change requires responses to be presented in a different way by indicating what server the response is from. Users upgrading from earlier versions must be aware of that and make appropriate changes in their scripts if needed. The fact Zabbix sender changed output should be documented in "Upgrade notes".
Fixed in pre-4.0.8 a1b2c3d, pre-4.2.2 1b2c3de
"Fixed"have to have empty value of
Fix Version/s. Without exceptions.
"Duplicate"should have linked duplicated issue. It is suggested to add a comment "closed as a duplicate" or similar - it makes it easier to follow who closed the issue.
In Jira, the following components are available. The letter in parenthesis match with letters in changelog entries and Git commit messages.
* API (A) * Documentation (D) * Frontend (F) * Agent (G) * Installation (I) * Java gateway (J) * Appliance (L) * Proxy (P) * Server (S) * Templates (T)
Documentation includes manpages and changelog fixes. Installation includes initial database schema and data, autotool related changes, and other similar issues. Templates deal with the templates that are shipped with Zabbix.
Each changelog entry and commit message since Zabbix 1.8.10 and 1.9.9 starts with a string that identifies components, changed in that commit or issue. It is a 10 character string (one per component) with component letter for each component that was changed, empty spaces filled with dots. Commit messages include only things that were changed in the commit itself, changelog entry includes all components that were changed regarding that issue.
Identification letters are always positionally placed like this:
For example, API and Frontend would be:
Server and proxy would be:
Commit messages that do not actually change any parts from the above (for example, merges, unit test edits) have all components unset:
Changes for 4.2.0rc2 New features: ..F....... [ZBXNEXT-5109] implemented test value saving before test sessions in preprocessing test forms (miks) ..F.....S. [ZBXNEXT-1238,ZBXNEXT-4988] added ability to test media types from UI (Ivo, vso) ..F....... [ZBXNEXT-5114] improved multiline input control (ashubin) ...G...... [ZBXNEXT-5123] added server address and port to the Zabbix sender output (wiper) Bug fixes: ..F....... [ZBX-15931] fixed triggers filter for php 5.4 (talbergs) ..F....... [ZBX-15839] fixed broken layout of the breadcrumbs in Safari browser (ashubin) ........S. [ZBX-15867] fixed invalid DNS being accepted when receiving discovery contents from Zabbix proxy (vso) A......... [ZBX-15821] fixed SQL statement performance used in template.unlink() method (Sasha)
(Eduard, Oleg, Toms)
To preserve backward compatibility when removing an API feature we first deprecate it till the next major release and only then remove it. The following needs to be done when deprecating an API feature:
When there is a need to change database schema and create a database patch, the following changes are necessary: # change database schema in
src/libs/zbxdbupgrade/dbupgrade_XXXX.c(each patch should be as atomic as possible and make minimal changes to the database), where
XXXXdenotes the major and minor version the patch is developed for (e.g.,
src/libs/zbxdbupgrade/dbupgrade_2030.cfor 2.3.x development):
XXXXis the version specifier described above and
YYYis a sequential identifier:
create/src/data.tmpl, if necessary:
frontends/php/include/defines.inc.php(only if mandatory database version has been changed):
frontends/php/include/schema.inc.phpfile with the new schema: