Zabbix.org - Recent changes [en]

User:Klz43a1

2012-05-17T00:23:02Z

New user account

User talk:PressRTbox

2012-05-16T14:46:45Z

deleted "[[User talk:PressRTbox]]" spam

MediaWiki:Spam-blacklist

2012-05-16T14:46:26Z

User:RipemiWoxaju

2012-05-16T10:08:01Z

deleted "[[User:RipemiWoxaju]]" spam

User:RipemiWoxaju

2012-05-16T10:07:57Z

blocked [[RipemiWoxaju (Talk | contribs)]] with an expiry time of infinite (account creation disabled, e-mail blocked) Spamming links to external sites

Só tenho uma coisa a dizer Os Renew bunitin tão virando viadin

2012-05-16T10:04:49Z

deleted "[[Só tenho uma coisa a dizer Os Renew bunitin tão virando viadin]]" spam

User:PressRTbox

2012-05-16T09:06:58Z

New user account

User:RipemiWoxaju

2012-05-16T09:05:35Z

New user account

User:TryfonMcwilliams

2012-05-16T00:49:25Z

New user account

Docs/specs/development guidelines

2012-05-15T18:25:00Z

move over more info

← Older revision		Revision as of 18:25, 15 May 2012
Line 1:		Line 1:
		+	== Version control ==
		+
		+	Zabbix uses Subversion/SVN for version control.
		+
		+	=== Branches ===
		+	* All changes should be first made in a development branch, which should be created in ''branches/dev'' ({{Command\|<nowiki>svn cp svn://svn.zabbix.com/branches/1.8 svn://svn.zabbix.com/branches/dev/ZBX-1234 -m ".......... [ZBX-1234] created new development branch to fix foo"</nowiki>}}).
		+	* Trivial fixes (e.g., typos) can be made directly in trunk and stable branch without independent testing. Developer is fully responsible for such changes. Translations and tests can also be updated without creating a separate dev branch.
		+	* All development branches should be named the same as the issue they are solving, including case. For instance, ZBXNEXT-512.
		+	* Issues referenced in branch names can only be from ZBX, and ZBXNEXT projects.
		+	* If work on a development branch takes a long time, changes from the source branch should be periodically merged into it (in the dev branch: {{Command\|<nowiki>svn merge svn://svn.zabbix.com/branches/1.8</nowiki>}}) and conflicts resolved.
		+	* After work on the development branch has been completed, source branch should be merged into it (in the dev branch: {{Command\|<nowiki>svn merge svn://svn.zabbix.com/branches/1.8</nowiki>}}) and committed before testing and code review may happen.
		+	* After successful testing and code review source branch should be merged into the development branch again, and development branch should be reintegrated back into the source branch (in the original branch: {{Command\|<nowiki>svn merge --reintegrate svn://svn.zabbix.com/branches/dev/ZBX-1234</nowiki>}}).
		+
		+
		+	{{Note\|Source branch should be merged into development branch prior to it's reintegration always, even if there are no conflicts (see [http://svnbook.red-bean.com/en/1.5/svn.branchmerge.basicmerging.html "Basic Merging"] for details).}}
		+
		+
		+	{{Note\|Periodic merging from the source branch and merging from the source branch prior the testing must happen because:<br/>a) it is better to discover and easier to solve conflicts as soon as possible and in smaller batches;<br/>b) when testing, it is not worth wasting time on a development branch which is outdated, compared to the current source branch;<br/>c) changes in the source branch may affect the functionality that is tested in the development branch}}
		+
		+
		+	* If there are any conflicts when merging into development branch, a commit message should indicate that.
		+	* If there are any conflicts when merging into trunk, someone else should review or test the merged changes.
		+	* Development branches should be removed immediately after they have been reintegrated ({{Command\|<nowiki>svn rm svn://svn.zabbix.com/branches/dev/ZBX-1234 -m ".......... [ZBX-1234] removing merged development branch"</nowiki>}}).
		+	* Merge commits also should have functional commit messages, "merged revision n" is not sufficient.
		+	* Use {{Command\|svn mv}} always to preserve modification history, never delete/add files when moving them.
		+
		+	=== Commits ===
		+
		+	* Changes should not be pooled in huge commits - instead, multiple smaller commits (with related changes limited to a single commit) are preferred.
		+	* All svn commits should include a short description of that commit - what was changed in the commit, not what is some future goal of that particular development branch. It should be possible for others to understand the nature of changes without looking at the diff. For example, if some error was caused by off-by-one, commit message should list both what problem it fixes and what was the cause for it.
		+	* Commit message format for direct changes:
		+	- [ISSUE] Description
		+	* Commit message format for merged changes:
		+	- [ISSUE] Description
		+	[merged BranchName <-c>FromRevisionNumber<:ToRevisionNumber>]
		+	* All svn commits should reference at least one JIRA issue so that the commits are visible on the tracker. If a change does not have an open issue on the tracker (e.g., a typo), one of generic issues (TODO: should link to these) should be used.
		+	* All svn commits that fix development bugs (TODO: should link to description of these) should include a list of development bugs fixed.
		+	* Issues referenced in svn commits can only be from ZBX and ZBXNEXT projects.
		+	* When fixing regressions, we should always find the commit(s) that broke that particular feature, so that we know what else could have been broken.
		+
	== Issue tracker ==		== Issue tracker ==

File:ShowShow 2389.jpg

2012-05-15T15:06:39Z

uploaded "[[File:ShowShow 2389.jpg]]"

MediaWiki:Spam-blacklist

2012-05-15T14:20:22Z

File:Destinationsdestinations 1980.jpg

2012-05-15T13:18:07Z

deleted "[[File:Destinationsdestinations 1980.jpg]]" spam

Docs/specs/ZBXNEXT-829

2012-05-15T09:03:46Z

Display notification in frontend when Zabbix server is not running:

← Older revision		Revision as of 09:03, 15 May 2012
(One intermediate revision by one user not shown)
Line 7:		Line 7:
	* if Zabbix server is not working, warning at the top of every frontend page should be shown		* if Zabbix server is not working, warning at the top of every frontend page should be shown
	* Zabbix server ip and port are taken from zabbix.conf.php file		* Zabbix server ip and port are taken from zabbix.conf.php file
−	* in Administration->General->GUI ~~two~~ new parameters ~~are~~ added: ~~enable/disable~~ server ~~check, period of checks. This option~~ is ~~global, it can not be customised per user~~	+	* in Administration->General->GUI one new parameters is added: "Zabbix server is running check interval". 0 - disabled, min value 30, max value 86400.
−	~~:I see a checking daemon in UI misplaced. A~~ check ~~whenever a page is (re)loaded should be enough~~. ~~For constant monitoring~~, ~~there should be an independent daemon like [http://linux.die.net/man/8/apphbd apphbd]~~, ~~probably with a compilation option/ini setting to register with it~~. ~~[[User:Ivan Pozdeev\|Ivan Pozdeev]] 21:47, 25 September 2011 (SAST)~~	+
−	:: introducing for something as (relatively) simple as showing whether zabbix server is up/down a dependency on a separate daemon would be a bit of an overkill, not to mention the need for this to function on bsd, aix, solaris... --[[User:Richlv\|Richlv]] 10:51, 26 September 2011 (EEST)	+
	* warning should be themable		* warning should be themable
	* warning should be translatable		* warning should be translatable
−	~~: what should~~ warning text ~~be like?~~ "Zabbix server ~~(127.0.0.1:10050)~~ is not running!"~~? [[User:Vedmak\|Vedmak]]~~	+	* warning text is "Zabbix server is not running!"
−	:: can we also include current timestamp and since when server is not running ? --[[User:Richlv\|Richlv]] 16:51, 4 July 2011 (SAST)	+	: can we also include current timestamp and since when server is not running ? --[[User:Richlv\|Richlv]] 16:51, 4 July 2011 (SAST)
−	~~::: by current you mean when last check was done? we can probably add approximate time since server died. [[User:Vedmak\|Vedmak]]~~	+
−		+
	* checks will happen every N secons. Client browser sends ajax request to frontend server (php) then frontend server tries to open socket to Zabbix server and sends result back to client.		* checks will happen every N secons. Client browser sends ajax request to frontend server (php) then frontend server tries to open socket to Zabbix server and sends result back to client.
−	* check interval is saved in config table and can be changed in Administration->GUI. 0 = checks are disabled.
	* socket timeout is defined as constant 3 seconds default.		* socket timeout is defined as constant 3 seconds default.
−		+	* warning is shown at the very top of the page.
−		+	* check results are cached in PHP session.
−	* ~~other things to decide: how will the~~ warning ~~look like - will it take full page width or not ? will it shift page contents down or flow over them ?~~	+	* if check interval is changed, opened pages need to be refreshed to apply change.
−	~~: i prefer full width and fixed position~~ at the very top of page ~~[[User:Vedmak\|Vedmak]]~~	+
−		+
−	* check results ~~should is~~ cached in PHP session	+

	[[Category:Specifications\|829]]		[[Category:Specifications\|829]]

File:Destinationsdestinations 1980.jpg

2012-05-15T06:58:45Z

uploaded "[[File:Destinationsdestinations 1980.jpg]]"

User:Theseisergasias

2012-05-15T05:03:28Z

New user account

File:Asian RestaurantAsian Restaurant 4999.jpg

2012-05-14T21:52:38Z

uploaded "[[File:Asian RestaurantAsian Restaurant 4999.jpg]]"

Docs/specs/ZBXNEXT-829

2012-05-14T14:26:19Z

← Older revision		Revision as of 14:26, 14 May 2012
Line 16:		Line 16:
	::: by current you mean when last check was done? we can probably add approximate time since server died. [[User:Vedmak\|Vedmak]]		::: by current you mean when last check was done? we can probably add approximate time since server died. [[User:Vedmak\|Vedmak]]

−	* checks will happen every N secons. Client browser sends ajax request to frontend server (php) then frontend server tries to open socket to Zabbix server and sends result back to client.	+	* checks will happen every N secons. Client browser sends ajax request to frontend server (php) then frontend server tries to open socket to Zabbix server and sends result back to client.
−	~~: socket timeout~~ is ~~~30 secs or~~ can be ~~configured probably, should define minimal check period? [[User:Vedmak\|Vedmak]]~~	+	* check interval is saved in config table and can be changed in Administration->GUI. 0 = checks are disabled.
−	~~:: maybe worth exposing timeout setting~~ in ''Administration~~->General~~->GUI~~'' as well ? --[[User:Richlv\|Richlv]] 16:48, 4 July 2011 (SAST)~~	+	* socket timeout is defined as constant 3 seconds default.
−	~~::: now it uses parameter from php~~.~~ini, it can be overridden but then we introduce new parameter~~. ~~[[User:Vedmak\|Vedmak]]~~	+
−	~~:::: ok, let's skip that for now and document where this value comes from --[[User:Richlv\|Richlv]] 17:54, 5 July 2011 (SAST)~~	+

	* other things to decide: how will the warning look like - will it take full page width or not ? will it shift page contents down or flow over them ?		* other things to decide: how will the warning look like - will it take full page width or not ? will it shift page contents down or flow over them ?
	: i prefer full width and fixed position at the very top of page [[User:Vedmak\|Vedmak]]		: i prefer full width and fixed position at the very top of page [[User:Vedmak\|Vedmak]]

−	* check results should be cached	+	* check results should is cached in PHP session
−	~~: we can keep cache~~ in ~~db, don't like this. Second option is create cache files, but then frontend will need write permissions for some folders. [[User:Vedmak\|Vedmak]]~~	+

	[[Category:Specifications\|829]]		[[Category:Specifications\|829]]

MediaWiki:Spam-blacklist

2012-05-14T10:20:06Z

Believe Digestion that life is worth living and your belief will help create that fact DontLetCrohnsKeepYouFromLiving

2012-05-14T10:08:23Z

deleted "[[Believe Digestion that life is worth living and your belief will help create that fact DontLetCrohnsKeepYouFromLiving]]" spam