Support/TikiWikiUpgrade

From MozillaWiki
Jump to: navigation, search

Background

SUMO is currently based on TikiWiki 1.10, a two year old version of Tiki that we've kept adding new features to while applying security patches and doing partial upgrades from Tiki upstream on select files. This has resulted in a situation where upgrading to the latest version of Tiki (currently 3.1, soon 4.0) will mean a lot of work.

In order to find a sustainable solution for SUMO in the long term, we need to decide on what the next step should be. In making the right decision, we need to factor in aspects like code quality and sustainability as well as community health.

One thing the three options have in common is that they all involve a significant amount of work in the short term, but the question is which one provides the healthiest solution in the long term.

Our three options

Upgrade

Upgrade to the latest stable version of TikiWiki and upstream future patches to ensure that we can continue to upgrade on each major TikiWiki release with minimal headache.

Pros

  • We can take advantage of the new TikiWiki features, such as Profiles (will allow us to create an "open source support" profile for TikiWiki that will be customized for the support website use case)
  • SUMO community will be accustomed to all website tools, including things like the wiki markup
  • Will pave the way for a healthy relationship with the TikiWiki community
    • More visibility of our SUMO-specific features (e.g. the l10n dashboard) since they'll be available to other projects too
    • We will become an actor instead of a consumer of TikiWiki -- our opportunity to give back to TikiWiki and demonstrate true Mozilla and open source values
    • Opportunity to share our experiences and insights about secure and efficient coding to change TikiWiki developers' mindset. ML: This is an opportunity for Tiki as well. Many things have improved since 1.10, we need more devs and more collaboration to make things go faster.
  • Support/BenefitsOfUpgradingToTiki4
  • Tiki has a predictable release schedule (twice per year) and each version will have features that are useful for SUMO, even if they weren't high enough on priority list to actually develop them.
  • Tiki has, built-in, most of the features that are needed for SUMO, which is why it was picked in the first place
  • Tiki project wants to have all the SUMO functionality discussed so far in Tiki core, and have available easily for anyone in next release. Full agreement on Support/SumoDevRoadmap2009 and we can presume that synergy in goals will always be there.
  • Tiki community members have volunteered in the past and have upstreamed stuff when put to their attention. The reason there is little recent collaboration is that the communities need to be more visible to each other and because Tiki devs are working on 4.x code, having long abandoned 1.10 code
    • Themes: Gary & luci have volunteered to make 4.x version and to work with SUMO to genericize interesting things. Ex.: Since 1.10, there several new fields (ex.: Site title subtitle, footer, etc.) that can managed via the admin panel (tiki-admin.php?page=look). And with workspaces, it becomes possible to override them by perspective. Site footer when user picks Fennec perspective is different the general site footer. (New in 4.0).
  • 5 SUMO developers have commit access to Tiki trunk, and all is needed is a SourceForge username to have more :-)

Cons

  • TikiWiki 4.x still has several major design flaws -- our best bet in the long term would be to rewrite some of these components to allow future scalability and extensibility
  • During the initial upgrade to 4.x, making sure that everything still works on SUMO will mean extensive QA and likely several bug fixes aside from our initial list of patches to upstream.
  • Once we've upgraded to 4.x, we will need to keep upstreaming our patches to TikiWiki trunk to ensure that our new features and bug fixes will be available when we upgrade TikiWiki to 5.x, 6.x, etc.
  • TikiWiki and SUMO often has quite different priorities. TikiWiki wants to create the equivalent of a CMS "operating system" -- a solution that can do pretty much anything. Our focus is to produce a high quality solution designed to fit our needs. ML: As SUMO is an active participant to the TikiWiki community, SUMO priorities are Tiki priorities.

Fork

Fork and leave TikiWiki behind altogether and develop our own solution independently of TikiWiki.

Pros

  • We could easily strip out 90% of the codebase
  • We could probably still "steal" new TikiWiki features if we wanted to by backporting
  • We could eventually rewrite major components and slowly get rid of our TikiWiki dependencies
  • No need to upgrade to the latest version of TikiWiki or upstream our future patches

Cons

  • We would still have to rewrite many of the components to ensure future scalability, but rather than working together with TikiWiki we would do it on our own
  • We could hardly call ourselves good open source citizens since we wouldn't give any of our fixes or feature additions back unless someone took our code and upstreamed it themselves

Port

Port SUMO to a different platform.

Pros

  • We could switch to a platform that focuses on scalability, performance, and extensibility, rather than a "Jack of all trades, master of none" platform
  • No need to upgrade to the latest version of TikiWiki or upstream our future patches

Cons

  • Unless we invested a crazy amount of time to make things feel unchanged, this would mean a radically different system for many of our community members' use cases:
    • Editing articles would likely be done with a different wiki syntax
    • Localization workflow would be different
    • Forum software would be different
  • This would definitely disrupt and alienate many SUMO community members who typically aren't excited about changed workflows -- just getting people to contribute on SUMO rather than another system has proved to be very difficult in the past
  • Would essentially mean that all further SUMO development would stop for a good amount of time (probably a full quarter at best)
  • Not clear how much of a benefit this would be in the end -- depends heavily on the platform chosen
  • Would likely have tons of regressions and broken use cases we didn't consider

What's needed to make a decision

  • Meeting with James/Laura/David/Marc/Paul for James to share some new architecture concerns and get to know each others' perspectives more -- Sept 2nd
  • Table of technical comparison between different CMS platforms (James)
  • Meeting with James/Laura/David/Marc/Paul/LPH so LPH can provide some initial responses on the feasibility of our architectural ideas
  • Completed work on SUMO bug triage to get a clear picture of resources needed to upgrade (David/Laura/Marc)
  • Response to our architecture concerns (LPH/Marc) -- due Sept 9th

Recommendations

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.

Solace

However, regardless of our choice, we think that Solace is a promising new project and want to keep an eye on it as it matures, especially when we get to updating the forum component.

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

  • By contributing our work back to the community (both existing patches and future refactoring work) we act as good open source citizens . I feel that this is an important criteria that distinguishes us as Mozilla versus a different type of organization.
  • Contribution of our patches makes future upgrades and staying in sync with the Tiki community much easier.
  • 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 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.
  • Things we get from Tiki 4:
    • PDO
    • Unit tests
    • tiki-setup rewrite
    • Security system rewrite
    • l10n placeholders
    • pagination support
    • permissions system rewrite
    • admin system rewrite
    • tags rewrite
    • editing UI improvements
    • profiles
    • More here: RoadMap

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.

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.

Forking, while upstreaming the patches we have now and backporting the changes we want, seems like the safest bet. It saves us a quarter that would otherwise be spent upgrading, and let's us get right into the growing backlog of SUMO bugs.

I'm also worried about the practicality of staying in sync:

Breakdown of triaged sumo bugs.png

sumo_only is the group of changes that we need to maintain during the syncs. Several of those are template changes, but things in sumo_triage or tiki_triage can also end up in sumo_only, and this is only the first ~1/4th of the bugs to triage.

Notes from Marc

When we made the categories, (sumo_only, tiki_bug, etc.), our goal was to evaluate how much work it was to upgrade. sumo_only is defined as: "Stuff that is related to the administration/maintenance of the SUMO website that can't really be upstreamed". So for us, that was stuff for which there was almost no work, work which is necessary/implicit anyway (with or without the upgrade), or that was included in a meta-bug.

Perhaps we should further categorize things to get a better picture. For example:

1- sumo_template -> sumo-specific templates that shouldn't be upstreamed (this could include minor features that are trivial to maintain). There will be work to upgrade to Tiki4, but fairly easy to manage and we have two volunteers (the two guys that redesigned Tiki themes in Tiki3).


2- sumo_feature -> Sumo_specific customization that can't be upstreamed and is not trivial to maintain, like a hardware-specific config. Ex.: SUMO rewrite rules, in-product help. Here, we should evaluate the meta-bug in its current global state and estimate porting to Tiki4 effort. Less work than the first time, but it can be significant if it touches somewhere where Tiki code changed a lot since 1.10.


3- Sumo_config -> Content or config handled by the CMS. No work expected.


4- sumo_onetime -> One time issue with load, etc. that we don't expect to ever deal with again. No work expected. But of course, we may discover new weird things.


5- sumo_included -> Stuff which is included already in another meta-bug (ex.: showfor, screencast, CSAT, minify, adding locales, etc.), as listed on Support/TikiUpstreamTriage. Please note that this could be a sumo_feature (like in-product) or a tiki_feature that should be upstreamed (ex.: showfor). The idea is that we upstream or port to Tiki4 only the latest version, which combines all previous Bugzilla items.

6- sumo-nottiki -> This would be things which have nothing to do with Tiki. Thus zero impact if we upgrade or not.

  • MySQL errors, etc.

7- sumo-tools -> Things like load tester. Here, perhaps we need to evaluate if it makes a difference if we upgrade or fork.

So, most of the items of sumo_only should be not too much work.

However, 1- The meta bugs can be huge 2- We'll have new features but also new bugs in Tiki4 (especially performance because no one stress-tested)

Notes from David

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
    • 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
    • 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
    • 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:
      • [One-time effort] The actual upgrade to Tiki 4.1 (not including the parts above about upstreaming and refactoring)
      • [Ongoing] More coordination/communication with the Tiki community to ensure that our refactoring doesn't break other sites
      • [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] 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

Retrieved from "https://wiki.mozilla.org/index.php?title=Support/TikiWikiUpgrade&oldid=1236606"