Quality Team

Intro

This team exists to monitor merges from trunk to the release branches for Tiki versions 3.x and 4.x.

The current members of the team (for 3.x and 4.x) are:

• Nyloth
• SylvieG
• JonnyB
• Sept_7
• Pkdille

Reasons for existence

The Quality Team was first conceived during the TikiFestMontreal2009 so developers can keep adding new things to trunk, and the best of them can be merged into forthcoming minor releases and the release branch doesn't become stagnant (as happened with 2.x)

Only the Quality Team and the Security Team are permitted to commit directly to the stable release branch, except for translations (where anyone can).

How it works

Devs should work on their fixes and enhancements in trunk (or an experimental branch first if it's really "out there"), and then commit that to the branches/proposals/4.x branch when tested thoroughly. If you also want to get your change into 3.x ("LTS" version) you should then commit the work (with suitable modifications where necessary) to branches/proposals/3.x

These "proposed" fixes should be done as a single commit (even if the original work in trunk took several goes to get right) so the whole change can be reviewed in one go, and if needs be, rolled back cleanly.

The commit message on branches/proposed should contain the revision number(s) and commit message(s) from trunk where this was first committed. If possible, wishlist id's when the commit fixes, or addresses any previously logged bugs. This is important because the Quality Team has the responsibility of checking that all commits to proposals has indeed been done in trunk first, and appropriately tested. It is also useful for all developers to have a clear log of who did what where, and why. A good explanation of the improvement will also help obtain a favorable decision for your work.



The team will discuss and vote on the proposed commits on the SVN Mailing List (which you should subscribe to!) to make the process as transparent, efficient and simple as possible.

The Quality Team will be alerted of new patches through the CVS/SVN mailing list after each commit. They will discuss the change together, evaluate the change by majority decision, and then approve and merge, or reject and rollback.

What will be considered

• In general, all feature enhancements must be optional and be "disabled" by default so users should not notice any change in operation without activating them.
• Major features will not be considered for back-porting - obviously the definition of major is subjective and debatable. Risk of introducing unexpected problems is a big decision factor. Developer time should mostly be focused on trunk. The Quality Team will judge and as a community, we can document a common understanding of what this is.
• Alterations to the database should be avoided: thus only critically needed and proven fixes should be proposed.
• Bug fixes should preserve existing behaviour as much as possible - The Three Rules still apply!
• All files needed for the enhancement or fix must be committed in a single revision. If you miss a file, or find that a subsequent fix is needed, than rollback the initial commit, and re-commit the whole lot in one go. This will make the members of the Quality Team smile on you!

Release process

The Quality Team will manage minor releases and hopes to release often (for example every month or three depending on activity). These releases will be "dot releases" e.g. 3.1, 3.2 etc.

The Security Team may need to release security updates between these releases and will operate in parallel with the Quality Team. These will be "dot dot releases" - e.g. 3.1.2

Conduct and recruitment

The membership of the team will be reviewed at every new release (every "six" months) and should be agreed by consensus through the tikiwiki-devel list, TikiFests and The Wiki-Way.

Members of the team cannot vote on their own back-ports, these must be approved by a majority of the other members of the team.

When you are ready

Commit to a proposals branch

Questions

• Is there a timeframe to deal with proposed commits? (Is there a "maximum" or "expected" time delay?)

See also

http://en.wikipedia.org/wiki/Change_control_board

Alias

• Quality Group
• Quality
• QT

---