From MozillaWiki
Jump to: navigation, search

The plan


  1. Early January: Get the infrastructure in place so we can upgrade SUMO with the latest Tiki code without affecting our local code
  2. January - March: Do regression testing and upstream anything that needs to be fixed in Tiki
  3. March: Upgrade to Tiki 5.1 by pulling down the latest code again, keeping the locally maintained code intact


1. Get the infrastructure in place

The plan is to figure out a way to combine locally maintained Tiki code that we haven't upstreamed (most notably the forum, our theme, and SHOWFOR) with the latest stable version of Tiki. This involves setting up an IT infrastructure where our locally maintained code isn't affected by a Tiki svn update.

As soon as LPH is done with upstreaming the remaining SUMO patches (early January) we should start the effort to get this infrastructure in place using the most recent Tiki code (currently in a 5.0-pre state). This includes getting to actually work so we can start regression testing.

Some local modifications to the code will most likely be needed to ensure that e.g. our Tiki 1.10 forum hooks into the latest Tiki code. The idea is that we do this as early in Q1 as possible and script it, or document anything that needs manual work. The goal is to have a working copy of SUMO with the latest Tiki code combined with our local fixes (theme, forum, SHOWFOR, etc) up at so we can start the actual regression testing.

Please see: Support/TikiUpgradeImplementation and Support/TikiTrunkTestingNotes

2. Regression testing & fixing

As we find problems on, we will patch and upstream all fixes to Tiki trunk to ensure that we don't run into the problem in the next upgrade cycle.

Of course, in addition to upstreaming our patches, we also apply them locally. In other words, our local Tiki installation will gradually stabilize throughout the regression testing/fixing process. And since we also upstream the patches, we can be confident that once we upgrade Tiki again to the stable version 5.1, we won't have to redo any of the upstreamed fixes along the way.

3. Upgrade to Tiki 5.1

At this point, Tiki 5.1 stable is released and our task is to pull down the latest Tiki code again -- keeping our local infrastructure intact using scripts or documented manual IT work -- and perform final QA.

If we still have problems, we will fix and upstream patches to Tiki trunk as usual, to ensure that we don't encounter this problem in a future Tiki 6.1 upgrade, but we won't pull down the latest source again in this upgrade cycle after this point.

After a successful upgrade

Upgrading to 5.1 is the big obstacle, since we haven't attempted to upgrade in over two years. After the upgrade is when the fun begins. :)

We will then be in sync with Tiki and can start to tackle bigger architectural problems that will improve the platform and benefit both communities. As we discover and fix bugs in Tiki, we will always upstream those fixes right away to Tiki trunk so the next upgrade to 6.1 is straightforward.

We should also strive to share code upstream whenever it makes sense. Some notable things we can do in 2010:

  • SHOWFOR and a few other things were not upstreamed into Tiki because they were written too specifically for SUMO. In 2010, we can rewrite SHOWFOR and other features into something better that can be maintained upstream. This will ensure more eyes on the features and potentially contributions from the Tiki community.
  • Our current SUMO theme contains a couple of copyrighted images. However, essentially 95% of the theme could be GLP/LGLP/MLP licensed. We could find a way to share those 95% as a base SUMO theme and only store the copyrighted artwork locally.
  • The only reason we are keeping the old Tiki 1.10 forum is because it's a local hack that we will rewrite from scratch in 2010. Once we're done with that, we could easily upgrade to the upstream version of the forum for traditional discussion forums like the Contributor forum, Off-topic forum, etc.


While we will strive to work together as much as possible for the benefit of both projects, we will also keep our autonomy to develop brand new functionality independently of the Tiki architecture whenever that makes more sense. As an example, when developing the revamped support forum component on SUMO, we don't have to upstream it patch by patch as we develop it; we can simply upstream it as one big module when we're done, which will improve our agility and speed.

Tiki 6.1 is scheduled for a release sometime in Q4 2010. In theory, that upgrade should be much more straightforward since we have ensured that we stay in sync with Tiki throughout 2010. If all goes well, it should require little effort from our end to stay up to date with Tiki in the future.