XWiki's Development Process
Eduard Moraru
2016
About XWiki
●
Web platform on top of
the wiki paradigm
●
Structured data, scripting,
applications
●
Java platform, polyglot
applications (JSR223)
●
XWiki Enterprise – the
product
●
LGPL license, since 2004
●
www.xwiki.org
XWiki Features
● Modular and highly extensible
●
Version control, attachments, user and rights
management, subwiki and subpages,
comments, wiki syntax and WYSIWYG editor,
macros, notifications, skins, search,
import/export, apps, etc.
● Use cases:
● Knowledge sharing and collaboration
● Intranets, knowledge base, public websites,
groupware, education, etc.
XWiki Enterprise
Community
● Users, Contributors and Core committers
●
Core and Contrib
●
Meritocracy
●
Governed by committers
● New committers voted based on contribution
● Lazy consensus
●
Important changes go through voting
●
+1, +/-0, -1
● Core committers have veto (-1) rights
Roadmap and Releases
● Timeboxing vs Feature-driven
●
Open roadmap for each minor release
●
1 major release per year
●
Minor releases (2.5 months)
● Dev releases (1-3 weeks)
● Bugfix releases
●
Support 3 versions (Dev, Stable & LTS)
● Release Manager Roster (taking turns)
●
Release Process on xwiki.org
Process: Community
Process: Mails
Process: Chat
Process: Issues
Process: Code
Process: Continuous Integration
Process: Quality
Process: Builds
Process: Product
Process: Websites
Process – Recap
●
Communication: Mailing Lists + IRC
● Issue Tracking: Jira
● Source Code Management: GitHub
● Continuous Integration: Jenkins
●
Build Repository: Nexus
● Documentation: (*.)xwiki.org
● Localization: l10n.xwiki.org
●
Extensions Repo: extensions.xwiki.org
● Code Quality: SonarQube
Dev Tools
● Source Control: Git
●
IDE: Eclipse, IntelliJ
●
Build Management: Maven 3
● Quality Control:
● Code style: Checkstyle
● Testing: JUnit/Mockito, Jacoco, Selenium 2
● Backwards compatibility: Revapi
Dev Principles
● High focus on quality
● dev.xwiki.org dedicated to dev documentation and
best practices
●
Enforcing coding style and min. test coverage
●
XWiki special days (Bug Fixing Days, etc.)
●
High focus on backwards compatibility
● Deprecation strategy
● Legacy modules
Statistics (1/2)
● 19 active committers
● 194 code contributors
●
60K commits
●
950K lines of code (Java)
●
67K mails
● 1K current subscribers
●
27.5K issues
●
(13% open; 53% bugs)
Statistics (2/2)
● 305 product releases
● (1 release every 15 days)
●
2.3M downloads
●
2200+ active instances
●
870+ extensions
● (200+ applications)
●
37 supported languages
● 9/12 years @ Google Summer of Code
Ways to Contribute
●
Pull Requests
●
github.com/xwiki
●
github.com/xwiki-contrib
● Translations
●
l10n.xwiki.org
● Documentation
●
xwiki.org
● New extensions
●
extensions.xwiki.org
Earning a living
● Multiple companies build their businesses on
top of XWiki
● XWiki.com is the main company sponsoring the
development of the project (since 2004)
● Professional Support
●
Consulting & Training
● Custom Development & Solutions
●
Hosting
●
Sustainable alternative to proprietary
Questions?
Thank you!
Eduard Moraru
Enygma2002

XWiki's Development Process

  • 1.
  • 2.
    About XWiki ● Web platformon top of the wiki paradigm ● Structured data, scripting, applications ● Java platform, polyglot applications (JSR223) ● XWiki Enterprise – the product ● LGPL license, since 2004 ● www.xwiki.org
  • 3.
    XWiki Features ● Modularand highly extensible ● Version control, attachments, user and rights management, subwiki and subpages, comments, wiki syntax and WYSIWYG editor, macros, notifications, skins, search, import/export, apps, etc. ● Use cases: ● Knowledge sharing and collaboration ● Intranets, knowledge base, public websites, groupware, education, etc.
  • 4.
  • 5.
    Community ● Users, Contributorsand Core committers ● Core and Contrib ● Meritocracy ● Governed by committers ● New committers voted based on contribution ● Lazy consensus ● Important changes go through voting ● +1, +/-0, -1 ● Core committers have veto (-1) rights
  • 6.
    Roadmap and Releases ●Timeboxing vs Feature-driven ● Open roadmap for each minor release ● 1 major release per year ● Minor releases (2.5 months) ● Dev releases (1-3 weeks) ● Bugfix releases ● Support 3 versions (Dev, Stable & LTS) ● Release Manager Roster (taking turns) ● Release Process on xwiki.org
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.
  • 12.
  • 13.
  • 14.
  • 15.
  • 16.
  • 17.
    Process – Recap ● Communication:Mailing Lists + IRC ● Issue Tracking: Jira ● Source Code Management: GitHub ● Continuous Integration: Jenkins ● Build Repository: Nexus ● Documentation: (*.)xwiki.org ● Localization: l10n.xwiki.org ● Extensions Repo: extensions.xwiki.org ● Code Quality: SonarQube
  • 18.
    Dev Tools ● SourceControl: Git ● IDE: Eclipse, IntelliJ ● Build Management: Maven 3 ● Quality Control: ● Code style: Checkstyle ● Testing: JUnit/Mockito, Jacoco, Selenium 2 ● Backwards compatibility: Revapi
  • 19.
    Dev Principles ● Highfocus on quality ● dev.xwiki.org dedicated to dev documentation and best practices ● Enforcing coding style and min. test coverage ● XWiki special days (Bug Fixing Days, etc.) ● High focus on backwards compatibility ● Deprecation strategy ● Legacy modules
  • 20.
    Statistics (1/2) ● 19active committers ● 194 code contributors ● 60K commits ● 950K lines of code (Java) ● 67K mails ● 1K current subscribers ● 27.5K issues ● (13% open; 53% bugs)
  • 21.
    Statistics (2/2) ● 305product releases ● (1 release every 15 days) ● 2.3M downloads ● 2200+ active instances ● 870+ extensions ● (200+ applications) ● 37 supported languages ● 9/12 years @ Google Summer of Code
  • 22.
    Ways to Contribute ● PullRequests ● github.com/xwiki ● github.com/xwiki-contrib ● Translations ● l10n.xwiki.org ● Documentation ● xwiki.org ● New extensions ● extensions.xwiki.org
  • 23.
    Earning a living ●Multiple companies build their businesses on top of XWiki ● XWiki.com is the main company sponsoring the development of the project (since 2004) ● Professional Support ● Consulting & Training ● Custom Development & Solutions ● Hosting ● Sustainable alternative to proprietary
  • 24.
  • 25.

Editor's Notes

  • #3 Applications: Apache Velocity + JSR223: Python, Groovy, JavaScript, PHP, Ruby, etc. Internal (scripting) and external APIs for CRUD data operations.
  • #7 Open Development, not just open Source Frequent releases = Early feedback No single Release Manager + documented process = low bus factor
  • #8 Users, devs, contributors
  • #9 Users, Devs, Notifications (central) - roadmap discussions - ask for help - votes, proposals, announcements - BFDs - asynchronous - publicly indexed by (3+) services and searchable by google - also has a forum-like view with nabble Alternative: forum - needs account, need to go on the forum to interact (even if notified by mail), etc.
  • #10 Synchronous discussions IRC Bot (XWiki) Application on xwiki.org - wiki modifs and code commits live notifications - Jira link completion - chat archive Freenode.org for OS projects and interractions Open, standard and well known protocol that already has (and is easy to add) many integrations even if maybe less sexy
  • #11 OSS license - Dashboards, filters, reports - Used in Roadmap tracking - more powerful than github issues - we started with Jira, hard to move away Contributors can assign and close issues - issues closed by PRs have proper assignee Core + Contrib exts GitHub integration We do not close older issues Mandatory documentation and release notes fields checked by the release process
  • #12 GitHub – the place to be, social, etc. xwiki & xwiki-contrib organizations Pull Requests Many code reviews for core, less picky for contrib extensions Cvs, svn, git (Hub) Alternative: Bitbucket - not interested in Mercurial or private repos We store at least 3 branches for all supported versions
  • #13 3 set of builds, 1 for each supported vers. Full integration, snapshots, up to distrib - unit tests, integration/functional tests for each module (minimal test instance) - security, web/accessibiltity standards - performance - quality (fails build if coverage not me + reports) - sonar metrics Screenshot of failing UI tests (even for older builds) See what commit breaks build Incremental builds on commit, full builds on manual trigger
  • #14 Quality level analysis - coverage, metrics, best practices, severity levels, architecture/design issues, etc. - technical debt - gives you a place to start when you want to improve something
  • #15 OSS License Proxy multiple repos + maven.xwiki.org/releases /externals /snapshots Core + Contrib exts Allows extensions to depend on each other and distributions to package extensions Used by maven builds of individual modules (without needing to rebuild everything)
  • #16 Product even if the result, is still connected to the project's infrastructure, even after it's installed and running (through EM/DW) Updates and new extensions from e.x.o (repository/index) - actually downloaded from either e.x.o or nexus.xwiki.org (if in core or contrib)
  • #17 Repo index + extension documentation Admin, install, config, high-level doc on xwiki.org + blog dev.xwiki.org – dev doc, best practices, etc. Translations Eating our own dogfood, various use cases of Xwiki (KB, App store, translation tool, etc.) Free to edit, monitored on IRC live and on mail (digests/watchlist)
  • #19 IntelliJ: OSS licenses
  • #24 Open by default Going open source is not an anti-pattern for a business Having a business contribute to a project helps the project overall