Support/TikiWikiUpgrade: Difference between revisions

Support/TikiWikiUpgrade (view source)

Revision as of 08:43, 25 September 2009

1 byte removed , 25 September 2009

→‎Notes from David

Djst

1,623

edits

Revision as of 21:26, 24 September 2009 (view source) Djst (talk \| contribs) (→‎Notes from David) ← Older edit		Revision as of 08:43, 25 September 2009 (view source) Djst (talk \| contribs) (→‎Notes from David) Newer edit →
Line 209:		Line 209:
	In response to the graph above from the initial bug triage: As Marc already pointed out, the sumo_only tag is not meant as "patches we'll need to re-apply every time we upgrade to a newer version of Tiki" -- quite the opposite: it's for bugs like one-time stuff (e.g. "launch Kampyle survey"), CMS administration (e.g. "changing permissions on users X"), or breakage specific to our servers (e.g. "stage server is down") -- in other words, it's for stuff that we shouldn't have to worry about in the upgrade effort.		In response to the graph above from the initial bug triage: As Marc already pointed out, the sumo_only tag is not meant as "patches we'll need to re-apply every time we upgrade to a newer version of Tiki" -- quite the opposite: it's for bugs like one-time stuff (e.g. "launch Kampyle survey"), CMS administration (e.g. "changing permissions on users X"), or breakage specific to our servers (e.g. "stage server is down") -- in other words, it's for stuff that we shouldn't have to worry about in the upgrade effort.

	We should always strive to minimize the number of patches on SUMO that ~~changes~~ Tiki but that we're not upstreaming for whatever reason; we all agree that having to maintain a set of patches that need to be re-applied for every future Tiki upgrade is not a good thing. Fortunately, the only real example of such a patch so far is our memcache implementation, which Tiki seems to want to implement differently. In other words, this is likely more of a theoretical concern than an actual one; staying in sync with Tiki between upgrades shouldn't be nearly as problematic as the graph suggests, as long as we're disciplined about upstreaming our patches.		We should always strive to minimize the number of patches on SUMO that change Tiki but that we're not upstreaming for whatever reason; we all agree that having to maintain a set of patches that need to be re-applied for every future Tiki upgrade is not a good thing. Fortunately, the only real example of such a patch so far is our memcache implementation, which Tiki seems to want to implement differently. In other words, this is likely more of a theoretical concern than an actual one; staying in sync with Tiki between upgrades shouldn't be nearly as problematic as the graph suggests, as long as we're disciplined about upstreaming our patches.