1,623
edits
Support/TikiWikiUpgrade: Difference between revisions
Jump to navigation
Jump to search
→Notes from David
| Line 202: | Line 202: | ||
*at least a quarter dedicated to upgrade and QA, and even if the gamble pays off, I don't feel it justifies the cost | *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: | ** 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: | ||
*** The actual upgrade to Tiki 4.1 (not including the parts above about upstreaming and refactoring) | *** [One-time effort] 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 | *** [Ongoing] 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] 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 | *** [Ongoing] Upstreaming of future patches | ||
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. | 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. | ||