Tiki Upstream Planning

Looking so far, my very rough, unscientific estimate is that a good day is getting two patches committed. More likely is less than 1.5 on average, to manually resolve conflicts, merge, and do enough BFT to know it's not completely broken.

One wrench in the estimation is that of the almost 900 or so closed (reso fixed or veri fixed) SUMO bugs [1], only around 200 have been triaged so far. I'll deal with this below.

Breakdown of triaged bugs

Bold are blockers in bugzilla.

tiki_feature

• Bug 398246 - no patches or revisions, partially server configurations
• Bug 395271 - patch
• Bug 480223 - revision number
• Bug 465518 - patches
• Bug 412265 - no patches or revision
• Bug 441858 - patch
• Bug 506547 - patch
• Bug 433341 - patch
• Bug 436679 - patch
• Bug 429784 - revisions
• Bug 498001 - patch, revisions
• Bug 492697 - patch, revisions, parallel work in tiki
• Bug 452830 - patch, sql
• Bug 465029 - patch, revision
• Bug 509864 - patch, revision

tiki_bug

• Bug 514244 - NEW, untargeted
• Bug 429529 - patch, revision
• Bug 512120 - patch, not in SVN
• Bug 485557 - revision, possibly fixed in tiki
• Bug 484100 - patch, revisions

tiki_fixed

21 bugs. At some point, will need to check that implementations are compatible.

tiki_triage

38 bugs. Not sure who's on this. marclaporte is on this but needs new categories (as discussed on sumo-dev-list) -> the new category is tiki_test and it has 60+ bugs in it, as of 2010-01-24

Untriaged bugs

A bugzilla search for closed (veri fixed or reso fixed) bugs in SUMO excluding Chat and Mobile yields 885 bugs ([2]).

Using the current percentages as a guide, there's a rough estimate of around 85 bugs to upstream, instead of the 20 we have triaged so far.

That would also leave around 160 bugs to check in Tiki.

Timeline

With an estimate of 85 bugs to upstream at ~1.5 bugs per day, that's 57 days of dev time, or around 11 weeks.

Resource wise, this corresponds with the initial estimate of one dev for a full quarter. We may also be able to get help from the Tiki community with this task.

The bug triage needs to be finished as quickly as possible so this estimate can be firmed up.

Questions

• How many of the triaged/untriaged bugs are just trackers? How many are much bigger/smaller that the 1.5 a day rate?
• How likely is it that the Tiki community would consider either a) holding 4.0 for our upstreamed patches or b) finding contributors to get these patches into 4.0 or c) a combination of both>
  • ML: a) If we know a while in advance, we can be flexible with respect to release schedules and we can align SUMO & Tiki roadmaps (So we could plan now for Tiki5 in February instead of April). However, Tiki4 release process is already started (http://dev.tikiwiki.org/Tiki4#Schedule). It would be very uncool for all the people that are working on it to change the schedule at this stage. We could rush in some non-risky things like extra language files. However, that would provide little value to SUMO.
  • ML: b) Yes, we do have volunteers in various areas that will help (ex.: themes, i18n, etc).
    • Perhaps the best is to start upstreaming everything to trunk and once everything is in, we could make a decision.
      • OptionA: Backport the fixes to Tiki4 branch for inclusion in 4.1, 4.2, etc.
      • OptionB: Ask for a stabilization on trunk for SUMO-used features. (Trunk is supposed to be releaseable at anytime, but sometimes, we downgrade to dogfoodable for a few weeks so we can all work on a major feature). When trunk is relatively stable for SUMO-used features, branch off a special branch (like a 4.5)
    • So backporting fixes in stable branch or branching off and from then on incorporating fixes from trunk: it's impossible to know at this stage what is the best option. It depends on 1- how (un)stable trunk is 2- How far away we are from the next release, etc. The first step is to upstream everything in trunk and a few weeks before we think we are up to date, we evaluate the situation and we make that call.