2. Where do we come from?
Condensed geographical plot of 1 year downloads by originating IP’s
3. Our development focus
• Community feedback used to expand on business goals
• Building for many distributions
• Provide a reliable partner relation
• Provide a stable product
• Be interactive in new innovations
• Be open to connect
4. Coordinating communities & Resources
Pootle Community HUB - Projects
GIT
Forums
Wiki IRC
Projects
Events Sites
JIRA
*.Zarafa.com
5. Listening and taking directions with community
Taking directions, using our ears, read your mail, and chat interactively.
– Created JIRA advanced tracker
– Opened WebApp Tracker
– GIT repo for direct source access
– IRC publishing of forum threads
– +8 Contributors of relevant substantial code
– Translators +25
– Visited 5 Major Events
– +16 Community projects and collections
– Forum refactor and renew
– Pushed community projects
6. Community HUB - Projects
Diverse projects with real user value and applications!
• PAM_MAPI for Zarafa
• SABREDAV
• SCRIPTS TOOLBOX
• MAILBRIDGE
• Zarafa Cluster Backup
• Fail2Ban integration
• Zarafa for Synology NAS
• ESET Linux Mailscanner integration
• Z-PUSH 2.0
• WebApp snapshots
10. Keep building structures
Everyday we grow
• Streamlining code contributions via GIT
Research an integration with JIRA tracker
• Integrate IRC & Forums more
• Stabilize Event presence
• Stimulate the Community projects
• Create Zarafa package Repo’s
for finals and beta’s + Nightly trunks
• More Community Hub functions,
antiSpam and Storage solution
12. Development at Zarafa
• How do bug reports
become releases?
• How do bug reports
and feature ideas
differ?
• How can I contribute
with high possibility of
acceptance?
14. How do bugreports become releases?
E-mail
Forum Phone
Support Issues ...
IRC Portal
Sales
15. How do bugreports become releases?
• Accept input, • Fix bugs
create issues • Implement
features
Support Development
Release QA
• Verify • Check that issues
completeness of are fixed
release • Check that feature
is implemented
correctly
16. How do bugreports become releases?
• Accept input, • Implement
create issues
Support Development
Planning
Release QA
• Verify • Check that issues
completeness of are fixed
release • Check that feature
is implemented
correctly
17. How do bugreports become releases?
Support Daily Sprint Merge Beta Release
• Create Jira Review planning • Merge if • Development • Release from
issues “open” on trunk only branch
• Quality check • For next 2
• Release weeks
outline
18. How do bugreports become releases?
QA cutoff
Sprint Sprint Sprint Sprint
•2 •2 •2 •2
weeks weeks weeks weeks
7.1.x 7.1.x+1 beta 7.1.x+1 final
19. How do bugreports become releases?
QA cutoff
Sprint Sprint Sprint Sprint
•2 •2 •2 •2
weeks weeks weeks weeks
7.1.x 7.1.x+1 beta 7.1.x+1 final
20. How do bugreports become releases?
QA cutoff
Sprint Sprint Sprint Sprint
•2 •2 •2 •2
weeks weeks weeks weeks
7.1.x 7.1.x+1 beta 7.1.x+1 final
21. How do bugreports become releases?
QA cutoff
Sprint Sprint Sprint Sprint
•2 •2 •2 •2
weeks weeks weeks weeks
7.1.x 7.1.x+1 beta 7.1.x+1 final
22. How do bugreports become releases?
QA cutoff
Sprint Sprint Sprint Sprint
•2 •2 •2 •2
weeks weeks weeks weeks
Beta2?
7.1.x 7.1.x+1 beta 7.1.x+1 final
23. How do bugreports become releases?
QA cutoff
Sprint Sprint Sprint Sprint
•2 •2 •2 •2
weeks weeks weeks weeks
Beta2?
7.1.x 7.1.x+1 beta 7.1.x+1 final
24. • Q: How do bug reports and feature ideas differ?
• A: Not at all
• A: They all start out as bug reports
• A: They all start out as feature ideas
25. How do bug reports and features differ?
FEAT project Feature
First planning Landed Planned Discarded Cloud
round
Version planning Unstable Supported
and sprints
26. • How can I contribute with high possibility of acceptance?
27. Total issues with input from 31
community:
Issues still open: 3
Issues accepted: 25
Issues rejected: 3
28. • Proprietary
svn • Multiple projects
• Only truth: releases are built from this
• Completely open: accepts merge
git requests
• Multiple projects
• Copy of svn for ZCP and WA projects
29. Contribution agreement
• Publish the contribution,
both in source and binary
forms;
• Modify and maintain the
contribution, to ensure Open source;
continued quality and includes all
contributions
Closed source and
binary; includes all
performance; contributions, also
OEM
• Relicense the
contribution, both in open
source and closed source
variants, also for OEM
distributors.