Support/TikiUpgradeImplementation: Difference between revisions
| Line 35: | Line 35: | ||
* Week of Jan 25 | * Week of Jan 25 | ||
** Fix and upstream remaining bugs - lph, paulc | ** Fix and upstream remaining bugs - lph, paulc (time for this is dependent on how many there are) | ||
** Test build scripts on tiki-trunk.m.c and iterate if necessary - jsocol | ** Test build scripts on tiki-trunk.m.c and iterate if necessary - jsocol | ||
** Fix remaining blocker bugs to tiki-trunk being useful - laura, paulc | ** Fix remaining blocker bugs to tiki-trunk being useful - laura, paulc | ||
* Week of Feb 1 | * Week of Feb 1 | ||
** Merge should be complete | ** Merge should be complete assuming not too many bugs to upstream | ||
** QA to work on verifying tiki-trunk | ** QA to begin work on verifying tiki-trunk | ||
Revision as of 21:18, 19 January 2010
This document details requirements for the high level TikiUpgradePlan.
Build infrastructure
To set up a working SUMO server will require integrating code from two separate codebases:
- TikiWiki. During testing this code will come from Tiki svn. Once Tiki 5.1 is stable, this code will come from SourceForge.
- Once TikiWiki code is in place, we will need to overlay local SUMO changes. This includes:
- Templates. We are keeping our own template process at least for the time being. New Tiki templates are in the database and we will need to do some performance testing to see if that's possible for us. This does not block the main upgrade. (see bug 537513#c7 for details)
- Other local changes that are not being upstreamed. The best example of this is (for now) our version of the Tiki 1.10 forums.
This overlaying process will include some addition of files (e.g. templates) and some replacement of files. It is not suitable to be done with svn externals.
We need to develop procedures for two things, which may be the same procedure, or not: 1. Procedure for setting up a development environment that is usable and that will allow checkins to both tiki-trunk and SUMO trunk. 2. Procedure for setting up a staging or production server including both sets of code.
Future Tiki Upgrades
The rationale for integrating two separate codebases is to make future Tiki upgrades as easy as possible. The procedure for this would then be:
- Upgrade Tiki install on a test server
- Update SUMO checkout to latest
- Run all tests and fix any issues, upstream changes in Tiki code, and update local code and settings accordingly.
Upstreaming
As each SUMO bug is triaged, we will decide which category it falls into:
- Tiki bug, to be upstreamed and included in the next Tiki release. These bug fixes will need to be applied locally. We will need to have some kind of cleanup process with each Tiki release where we remove code from the local codebase. (I'm not happy with this part of the process but the only other alternatives I can see are waiting for the next Tiki upgrade to fix, or running Tiki trunk in production, both of which are even less attractive.)
- New feature, to be included as part of SUMO local code and upstreamed as a whole into next Tiki release if wanted by the Tiki community
- SUMO only, to be included as part of SUMO local code and templates
Timeline and responsibilities
- Week of Jan 19
- Spec build process - jsocol, laura, oremj
- Write build scripts - jsocol
- Work on bugs blocking tiki-trunk - paulc
- Go through remaining tiki_discuss list - laura, jsocol, marclaporte, djst
- Week of Jan 25
- Fix and upstream remaining bugs - lph, paulc (time for this is dependent on how many there are)
- Test build scripts on tiki-trunk.m.c and iterate if necessary - jsocol
- Fix remaining blocker bugs to tiki-trunk being useful - laura, paulc
- Week of Feb 1
- Merge should be complete assuming not too many bugs to upstream
- QA to begin work on verifying tiki-trunk