1,623
edits
Support/TikiWikiUpgrade: Difference between revisions
Jump to navigation
Jump to search
→Option 2
| Line 137: | Line 137: | ||
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. | 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=== | ===Notes from Marc=== | ||
| Line 181: | Line 180: | ||
*[https://bugzilla.mozilla.org/show_bug.cgi?id=485644 Remove es-MX locale (revert Bug 482532)] | *[https://bugzilla.mozilla.org/show_bug.cgi?id=485644 Remove es-MX locale (revert Bug 482532)] | ||
*[https://bugzilla.mozilla.org/show_bug.cgi?id=480463 Layout broken in Safari 3.2.1 / IE 6 due to Minify] | *[https://bugzilla.mozilla.org/show_bug.cgi?id=480463 Layout broken in Safari 3.2.1 / IE 6 due to Minify] | ||
6- sumo-nottiki -> This would be things which have nothing to do with Tiki. Thus zero impact if we upgrade or not. | 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. | * 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. | 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. | So, most of the items of sumo_only should be not too much work. | ||
| Line 197: | Line 192: | ||
1- The meta bugs can be huge | 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) | 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 you're making 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 | |||
** There is indeed speculation that by being a good open source citizen, we will benefit from participation from the Tiki community. However, based on the e-mails received the last few weeks from people like Marc, Stephane Casset, Alain Desilets, luci, and Gary, it's not just speculation -- it's actually happening 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. That the added cost of upgrading is: | |||
*** The actual upgrade to Tiki 4.1 (not including the parts above about upstreaming and refactoring) | |||
*** More coordination/communication with the Tiki community to ensure that our refactoring doesn't break other sites | |||
*** 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 patches for future bug fixes (not including the bugs in the initial upgrade) | |||
Also, in response to the graph from the initial bug triage: As Marc already pointed out, the sumo_only tag was used for many different type of bugs and doesn't mean stuff we'll need to maintain through releases, but rather one-time stuff, CMS administrational things like changing permissions on objects, or breakage specific to our servers -- in other words, stuff that we shouldn't have to worry about now or in the future. So in reality, that tall bar in the graph does not represent patches we'll need to re-apply for each upgrade -- in fact we should always strive to minimize those type of patches. | |||