900
edits
Support/TikiWikiUpgrade: Difference between revisions
category -> Support Archive
(category -> Support Archive) |
|||
| (8 intermediate revisions by 2 users not shown) | |||
| Line 29: | Line 29: | ||
***[[Support/UpgradeToTiki4/ThemeCoordination]] | ***[[Support/UpgradeToTiki4/ThemeCoordination]] | ||
***Live at: http://sumo.ourwiki.net/ | ***Live at: http://sumo.ourwiki.net/ | ||
* | *[http://sourceforge.net/project/memberlist.php?group_id=64258 5 SUMO developers have commit access to Tiki trunk], and all is needed is a SourceForge username to have more :-) | ||
'''Cons''' | '''Cons''' | ||
| Line 194: | Line 194: | ||
===Notes from David=== | ===Notes from David=== | ||
Here's my attempt to distill the main points | Here's my attempt to distill the main points James is making in "proposal 2" and respond to them one by one: | ||
* Upgrading gives very little concrete benefit [...] the only concrete benefit that we would actually use is the migration PDO | * Upgrading gives very little concrete benefit [...] the only concrete benefit that we would actually use is the migration PDO | ||
** Based on Laura's list above, PDO is far from the only benefit | ** Based on Laura's list above, PDO is far from the only benefit | ||
* There is a lot of speculation, but it's an extremely costly gamble | * There is a lot of speculation, but it's an extremely costly gamble | ||
** | ** I think the main speculation here is that we'll benefit from increased participation (or participation period) from the Tiki community if we start to work more closely with them. However, based on the e-mails received the last few weeks from people like Marc, Stephane Casset, Alain Desilets, luci, and Gary, I would argue that it's not just speculation -- participation from Tiki actually started to happen already. | ||
*at least a quarter dedicated to upgrade and QA, and even if the gamble pays off, I don't feel it justifies the cost | *at least a quarter dedicated to upgrade and QA, and even if the gamble pays off, I don't feel it justifies the cost | ||
** The difference in cost between forking and upgrading doesn't seem significant here. Both involve upstreaming patches to Tiki and refactoring parts of the CMS, which is the significant effort. The added cost of upgrading then breaks down into: | ** The difference in cost between forking and upgrading doesn't seem significant here. Both involve upstreaming patches to Tiki and refactoring parts of the CMS, which is the significant effort. The added cost of upgrading then breaks down into: | ||
*** The actual upgrade to Tiki 4.1 (not including the parts above about upstreaming and refactoring) | *** [One-time effort] The actual upgrade to Tiki 4.1 (not including the parts above about upstreaming and refactoring) | ||
*** More coordination/communication with the Tiki community to ensure that our refactoring doesn't break other sites | *** [Ongoing] More coordination/communication with the Tiki community to ensure that our refactoring doesn't break other sites | ||
*** More QA for every future upgrade/sync (Tiki 5.1, 6.1, etc) to ensure that new features/fixes in upstream Tiki don't break SUMO | *** [Ongoing] More QA for every future upgrade/sync (Tiki 5.1, 6.1, etc) to ensure that new features/fixes in upstream Tiki don't break SUMO | ||
*** Ongoing | *** [Ongoing] Upstreaming of future patches | ||
In response to the graph above from the initial bug triage: As Marc already pointed out, the sumo_only tag is not meant as "patches we'll need to re-apply every time we upgrade to a newer version of Tiki" -- quite the opposite: it's for bugs like one-time stuff (e.g. "launch Kampyle survey"), CMS administration (e.g. "changing permissions on users X"), or breakage specific to our servers (e.g. "stage server is down") -- in other words, it's for stuff that we shouldn't have to worry about in the upgrade effort. | |||
We should always strive to minimize the number of patches on SUMO that change Tiki but that we're not upstreaming for whatever reason; we all agree that having to maintain a set of patches that need to be re-applied for every future Tiki upgrade is not a good thing. Fortunately, the only real example of such a patch so far is our memcache implementation, which Tiki seems to want to implement differently. In other words, this is likely more of a theoretical concern than an actual one; staying in sync with Tiki between upgrades shouldn't be nearly as problematic as the graph suggests, as long as we're disciplined about upstreaming our patches. | |||
=Decision= | |||
We will go with the Upgrade option and upgrade to TikiWiki 4.1 or 5.1 in early 2010. See [[Support/TikiUpstreamPlanning]] | |||
[[Category:Support Archive]] | |||