|
|
| (4 intermediate revisions by 2 users not shown) |
| Line 4: |
Line 4: |
| This document is a plan for engineering a sustainable platform for SUMO. The goals are: | | This document is a plan for engineering a sustainable platform for SUMO. The goals are: |
| * Evaluate the updated Tiki platform for suitability as a codebase that can continue to grow and improve with SUMO and with other projects using it for support | | * Evaluate the updated Tiki platform for suitability as a codebase that can continue to grow and improve with SUMO and with other projects using it for support |
| * Improve code platform quality to | | * Improve SUMO code platform quality to |
| ** Increase robustness and performance | | ** Increase robustness and performance |
| ** Increase developer happiness | | ** Increase developer happiness |
| ** Reduce time to implement new features | | ** Reduce time to implement new features |
|
| |
|
| = Tiki Upgrade = | | = Tiki Evaluation = |
| 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]].
| | [[Support/PlatformEngineeringTikiEvaluation]] discusses our evaluation of TikiWiki 5.1 as a possible future development platform. We arrived at a decision to rewrite the SUMO platform from scratch. |
|
| |
|
| = Evaluation = | | = Kitsune = |
| 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.
| | [[Support/Kitsune]] is our project to reimplement SUMO. |
|
| |
|
| We had originally intended porting our production instance to 5.1, running through a couple of release cycles, and then evaluating. However, we can reduce time to evaluate and possible investment by performing this evaluation earlier. Finishing upstreaming gets us to the point of having paid our ethical debt to TikiWiki by giving back our changes and improvements to the community, so this was important to complete.
| | = Frameworks = |
| | [[https://spreadsheets.google.com/ccc?key=0Ao5KB_TZOvbVdGhxNVlad2YxSW55Qy1wRnhWZmhJX1E&hl=en Framework Matrix]] looks at possible languages and frameworks for building the new SUMO. |
|
| |
|
| The evaluation criteria are as follows:
| | [[Category:Support Archive]] |
| * TikiWiki 5.1 Codebase: This can be evaluated by looking at the code and running tests against tiki-trunk.mozilla.com.
| |
| ** Is the new codebase easier to understand and develop further than the old one? That is, will it be easier/more enjoyable for our webdevs to do their jobs? [all devs, subjective]
| |
| ** Will we be able to get more done in a release cycle? [all devs, subjective]
| |
| ** Is the new codebase more robust? [all devs, subjective]
| |
| ** Is the new codebase at least as performant as the old one? [?, objective: run perf tests]
| |
| ** Is the new codebase actively good on each of these criteria, as opposed to just better than before? [all devs]
| |
| ** How does the current codebase perform versus our litmus tests? [WebQA, objective: litmus tests] (We will not be able to run Selenium tests without porting themes as it depends on the DOM.)
| |
| | |
| * Our implementation
| |
| ** How would we implement our build process in order to keep our TikiWiki up to date? [laura, [[https://wiki.mozilla.org/Support/BuildProcessTiki51 Draft Build Process]]
| |
| ** How will we separate out our local changes that are not going to be upstreamed to TikiWiki? [laura, [[https://wiki.mozilla.org/Support/BuildProcessTiki51 Draft Build Process]]
| |
| ** What is the scope of these local changes?
| |
| ** What is the complexity and time required to create and maintain a local codebase consisting of templates, modules, and overridden files?
| |
| ** How would this affect the deployment process and our desire to move towards continuous integration?
| |
| ** What new local code do we need to write or rewrite in order to run Tiki 5.1?
| |
| ** How much work would it be to update our SUMO themes to work with Tiki 5.1?
| |
| ** 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 =
| |
| | |
| 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 ==
| |
| 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
| |
| * Impact of refactoring: choose areas that will have the biggest impact for users and developers
| |
| * 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 =
| |
| In Q3 2009 we discussed three options: Upgrade, Fork, or Port (see [[https://wiki.mozilla.org/Support/TikiWikiUpgrade]]).
| |
| | |
| == Forking ==
| |
| 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 support two code repositories
| |
| | |
| If we have reached this point by giving the TikiWiki 5.1 codebase a negative evaluation, then the Fork option is less attractive than it once was. The main advantages are
| |
| * User and contributor experience would remain the same
| |
| * We have working code and would not need to invest time reimplementing features
| |
| | |
| | |
| == 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.
| |
| | |
| When considering this option we should remember the pros and cons of porting to a new platform that [https://wiki.mozilla.org/Support/TikiWikiUpgrade#Port we analyzed previously].
| |
| | |
| If we were to implement from scratch we would use a modern web framework such as Zend Framework, Kohana, or Django. For this application I would recommend one of the more full featured frameworks (ie probably not Kohana) for the ready availability of reusable components, which would reduce implementation time.
| |
| | |
| 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.
| |
