1,107
edits
Support/TikiWikiUpgrade: Difference between revisions
→Recommendations from James and Laura
MarcLaporte (talk | contribs) No edit summary |
|||
| Line 76: | Line 76: | ||
* Response to our [http://dev.tikiwiki.org/Architecture+Suggestions+From+Mozilla architecture concerns] (LPH/Marc) -- due Sept 9th | * Response to our [http://dev.tikiwiki.org/Architecture+Suggestions+From+Mozilla architecture concerns] (LPH/Marc) -- due Sept 9th | ||
=Recommendations | =Recommendations= | ||
After working out the details of our various options, this is where we are as of 23 | After working out the details of our various options, this is where we are as of 23 September. | ||
== | ==No porting at this stage== | ||
Porting would give us some concrete benefit in a cleaner upgrade and maintenance path, in a (theoretically) more modular and scalable platform, and in a more modern, cleaner code base; and some potential benefit in terms of feature turn-around times. However, the cost is extremely high as we would have to reimplement all the SUMO specific features inside a different application framework. We would also make life harder for the SUMO contributors as they would have to learn a new platform. As a result, we have ruled out any kind of porting at this stage. | |||
== | We suggest two possible options (one favored by each of us). The basis of both these options is to continue using the existing code, and either upgrade it or fork it. Overall, we believe porting or complete reimplementation at this stage is not a good option, as the cost (including opportunity cost) is too high. | ||
==Option 1== | |||
(preferred by Laura) | |||
Summary: Upgrade to 4.x, upstream patches, and then refactor, contributing our work back to the TikiWiki project. | |||
Under this option we would upgrade Tiki to 4.x, and then embark on a serious program of refactoring. We would, as an early priority, rewrite the forums. The upgrade would give us the benefit of two years of work by the Tiki community including security and performance enhancements. | |||
The forums are the slowest part of Tiki that we use (and we are the biggest users of same). In our research, all forum options are fairly awful, so we think we can do better and build in the features needed for a support-specific forum rather than a general discussion forum. | |||
Advantages: | |||
- We get the latest version of Tiki which has been through QA as a whole. I am not in favor of partial backporting of selected features. We've done this in the past, and it ends up taking a long time and causing regressions. | |||
- By contributing our work back to the community (both existing patches and future refactoring work) we both act as good open source citizens, and stay in sync with the Tiki development efforts, making future upgrades much easier. | |||
- By making a decision to reimplement/refactor parts of Tiki to be better we are freed up from the duct tape approach we have used in the past, and will also be making the base code a better product in future releases. | |||
Disadvantages: | |||
- This approach has more upfront work to get on to the Tiki 4.x branch. This would seriously limit the amount of SUMO specific work we could do in Q4. I would argue that this is effectively the start of the refactoring work, however, and at some point we need to spend time on refactoring. This approach front loads that portion of the work. | |||
- Tiki 4.x will have a new set of bugs so we will see a rise in issues at the beginning. | |||
==Option 2== | |||
(preferred by James) | |||
Summary: Fork, while upstreaming the patches we have now and backporting the changes we want. | |||
In terms of cost and benefit, I think the best action is forking. | In terms of cost and benefit, I think the best action is forking. | ||
Upgrading gives very little concrete benefit, the reason I've been against this option is that the only concrete benefit that we would actually use is the migration PDO--which is significant but very limited in scope, and could be backported. There is a lot of speculation, but it's an extremely costly gamble: at least a quarter dedicated to upgrade and QA, and even if the gamble pays off, I don't feel it justifies the cost. | Upgrading gives very little concrete benefit, the reason I've been against this option is that the only concrete benefit that we would actually use is the migration PDO--which is significant but very limited in scope, and could be backported. There is a lot of speculation, but it's an extremely costly gamble: at least a quarter dedicated to upgrade and QA, and even if the gamble pays off, I don't feel it justifies the cost. | ||