Support/TikiWikiUpgrade: Difference between revisions

Support/TikiWikiUpgrade (view source)

1,363 bytes added , 24 September 2009

664

edits

@@ Line 80: / Line 80: @@
 ==James==
+In terms of cost and benefit, I think the best action is forking.
+Porting would give us some concrete benefit in a cleaner upgrade and maintenance path, in a more modular and scalable platform, and in a more modern, cleaner code base; and some potential benefit in terms of feature turn-around times. But the cost is extremely high.
+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:
+[[File:Breakdown_of_triaged_sumo_bugs.png|center]]
+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.