1,107
edits
Support/PlatformEngineering: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 9: | Line 9: | ||
** Reduce time to implement new features | ** Reduce time to implement new features | ||
= Tiki Upgrade = | = Background = | ||
== Tiki Upgrade == | |||
In Q3 2009 [https://wiki.mozilla.org/Support/TikiWikiUpgrade we decided] that Q1 2010 will be occupied with getting SUMO running on Tiki 5.1. We have both a [[Support/TikiUpgradePlan|high level plan]] and a [[Support/TikiUpgradeImplementation|detailed implementation plan]]. In summary, the plan is/was to upstream our patches and then upgrade. | In Q3 2009 [https://wiki.mozilla.org/Support/TikiWikiUpgrade we decided] that Q1 2010 will be occupied with getting SUMO running on Tiki 5.1. We have both a [[Support/TikiUpgradePlan|high level plan]] and a [[Support/TikiUpgradeImplementation|detailed implementation plan]]. In summary, the plan is/was to upstream our patches and then upgrade. | ||
= Evaluation = | == Evaluation == | ||
During the upstreaming process, we have developed some concern about the viability of building on top of Tiki 5.1, as the upstreaming and initial testing has not gone as smoothly as planned. We will hence re-evaluate our options once the upstreaming is finished, before we actively port our production instance. | During the upstreaming process, we have developed some concern about the viability of building on top of Tiki 5.1, as the upstreaming and initial testing has not gone as smoothly as planned. We will hence re-evaluate our options once the upstreaming is finished, before we actively port our production instance. | ||
| Line 36: | Line 38: | ||
** Related to above question: how much additional work would it be to keep the new templates consistent with the old w.r.t. user/contributor experience? | ** Related to above question: how much additional work would it be to keep the new templates consistent with the old w.r.t. user/contributor experience? | ||
= Option 1: continue with Tiki = | == Option 1: continue with Tiki == | ||
One of the rationales for upgrading Tiki to current was to enable us to rewrite parts of the code as we see fit. This includes improving existing sections of core code and modules. | One of the rationales for upgrading Tiki to current was to enable us to rewrite parts of the code as we see fit. This includes improving existing sections of core code and modules. | ||
== Refactoring == | === Refactoring === | ||
We need to identify which parts of Tiki we plan to rewrite or refactor. The criteria for choosing these are as follows: | We need to identify which parts of Tiki we plan to rewrite or refactor. The criteria for choosing these are as follows: | ||
* Existing poor code quality and/or fragility | * Existing poor code quality and/or fragility | ||
| Line 46: | Line 48: | ||
* Ease of refactoring: While this would never be the only criteria, there is certainly value in choosing low hanging fruit | * Ease of refactoring: While this would never be the only criteria, there is certainly value in choosing low hanging fruit | ||
= Option 2: Redevelop SUMO platform = | == Option 2: Redevelop SUMO platform == | ||
In Q3 2009 we discussed three options: Upgrade, Fork, or Port (see [[https://wiki.mozilla.org/Support/TikiWikiUpgrade]]). | In Q3 2009 we discussed three options: Upgrade, Fork, or Port (see [[https://wiki.mozilla.org/Support/TikiWikiUpgrade]]). | ||
== Forking == | === Forking === | ||
Having upstreamed the vast majority of our changes, the Fork option differs from Upgrade in the following respects: | Having upstreamed the vast majority of our changes, the Fork option differs from Upgrade in the following respects: | ||
* No need to work out complex build and deployment process | * No need to work out complex build and deployment process | ||
| Line 59: | Line 61: | ||
== Porting == | === Porting === | ||
The outcome of the Porting options matrix we developed in Q3 2009 ([[https://spreadsheets.google.com/ccc?key=0Ao5KB_TZOvbVdDgtSEdRNnNyeDBvWUtJOUZYZnU0Rnc&hl=en]]) was that none of the other existing platforms look significantly better than TikiWiki. That means that this option represents reimplementing the platform from scratch. | The outcome of the Porting options matrix we developed in Q3 2009 ([[https://spreadsheets.google.com/ccc?key=0Ao5KB_TZOvbVdDgtSEdRNnNyeDBvWUtJOUZYZnU0Rnc&hl=en]]) was that none of the other existing platforms look significantly better than TikiWiki. That means that this option represents reimplementing the platform from scratch. | ||
| Line 67: | Line 69: | ||
We would need to work up an SRS of features that require/actually use and prioritize these. It may be possible to move parts of the code over before the new system is complete. For example, we have discussed reimplementing forums. We could implement forums in the new system and then migrate them over. | We would need to work up an SRS of features that require/actually use and prioritize these. It may be possible to move parts of the code over before the new system is complete. For example, we have discussed reimplementing forums. We could implement forums in the new system and then migrate them over. | ||
== Evaluation Outcome == | |||
As a result of the SUMODEV meeting on 01/25/10, we decided not to move ahead with the TikiWiki upgrade. | |||
=== Rationale === | |||
* Looking at the new code, while some architectural improvements have been made and many features added, it is apparent that improvements have not been made in the parts of the code that we use. | |||
* Some portions of the code have become even more bloated, in particular tiki-js.js which has ballooned from 1200LOC to 1700LOC, and tikilib, which has been partially split off into wikilib but managed to grow nonetheless. These were two of our original pain points in Q3. | |||
* Each feature has been harder to upstream than anticipated. A larger number than anticipated have not and will not be upstreamed and would require local maintenance. | |||
* Some upstreamed features have been adapted to work differently (for example CSAT) and we would have to either support our local versions or rewrite our code to work with the Tiki versions. Some existing features have this problem as well (themes). | |||
* Having to work around this local adaptation of features will slow our release velocity. | |||
* It still seems difficult if not impossible to incorporate unit tests. We cannot see a situation where it would be possible to have decent coverage. The new code is not more robust and definitely not more testable. | |||
* Perceived performance is much slower. This is already a pain point for our contributors and we cannot afford to have it get worse. | |||
* The increased complexity of releases and adaptations needed would flow on to other projects using SUMO (MoMo and Firefox for Mobile). | |||
=== Next steps === | |||
We plan to undertake a rewrite of SUMO, likely component by component. The dev team will meet ASAP to formulate an initial plan. | |||