Support/TikiUpstreamPlanning

From MozillaWiki
Jump to: navigation, search

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

tiki_bug

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.

Component Triaged Bugs % of all Triaged Bugs Estimated total (% * 885)
tiki_feature 15 7.18% 64
tiki_bug 5 2.39% 21
tiki_triage 38 18.18% 161
tiki_fixed 21 10.05% 89
sumo_triage 15 7.18% 64
sumo_only 115 55.02% 487

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.
Retrieved from "https://wiki.mozilla.org/index.php?title=Support/TikiUpstreamPlanning&oldid=1236604"