request for comments : improving zabbix after 1.6

[richlv]

we are trying to define a list of possible zabbix improvements to push for _after _ version 1.6. this list includes only items deemed interesting enough for our organisation, thus possibly excluding some items very important for somebody else

this list is in no way connected to the official zabbix team and neither actual features, nor their priorities reflect views of the zabbix team.

some of these are lifted from 1.6 suggestions thread. if you see your suggestion here misinterpreted or not clear enough, tell about that.

this is initial listing and thus has many problems. any help would be vey appreciated - that includes language/typo fixes, improvement of descriptions and commenting on technical and overall feasability of items listed.

if an item included here is already implemented, will be implemented in 1.6 or you intend to implement or finance it - speak up. avoiding duplicating efforts will lead to more features getting implemented in the end.

hmm. unfortunately, odt is not allowed on this forum. if anybody would like the list in odt format, i can send it.
also, i can export it to mediawiki format, but as importing isn't too great yet, i haven't done that

[Niels]

Hi,

many of your suggestions are good, some I can't comment on. There really ought to be a public Bugzilla (or equivalent) where we could vote on such suggestions. That's a large problem: The closed development model you mention. I'm a PHP developer, and if I choose to continue using Zabbix, I'll probably start modifying the frontend. I don't personally like the coding style and there are no comments, which adds to the difficulties.

Encrypted communication, lighter server load, DM and better documentation are probably my main problems at the moment.

[lunix]

Development Model

Hi,

many of your suggestions are good, some I can't comment on. There really ought to be a public Bugzilla (or equivalent) where we could vote on such suggestions. That's a large problem: The closed development model you mention. I'm a PHP developer, and if I choose to continue using Zabbix, I'll probably start modifying the frontend. I don't personally like the coding style and there are no comments, which adds to the difficulties.

Encrypted communication, lighter server load, DM and better documentation are probably my main problems at the moment.

I couldn't agree more, there is this free open source project called 'trac' from edgewall software that provides websvn, wiki, forum and a couple more features that could be useful. If there is interest i could provide more info or even lend a hand setting it up, though their website is pretty mutch self explanatory.

[dminstrel]

Using Trac for ZABBIX development was already suggested in several posts. I don't know if Alexei had time to take a look at it. Trac would go a long way to making ZABBIX developement more "external developpers-friendly".

Cheers,

[richlv]

actually, there is a wiki (it's messy, but that's another matter), forum and svn.

the most visible thing missing - open bugtracker.

my guess would be that trac won't be used, but i have high hopes for an open bugtracker

and with that being available, most important technological piecies would be in place, leaving psychological and organisational barriers.