Support/TikiWikiUpgrade - Revision history

Kelimutu: category -> Support Archive

2021-07-14T08:57:40Z

category -> Support Archive

← Older revision		Revision as of 08:57, 14 July 2021
Line 213:		Line 213:
	=Decision=		=Decision=
	We will go with the Upgrade option and upgrade to TikiWiki 4.1 or 5.1 in early 2010. See [[Support/TikiUpstreamPlanning]]		We will go with the Upgrade option and upgrade to TikiWiki 4.1 or 5.1 in early 2010. See [[Support/TikiUpstreamPlanning]]

			[[Category:Support Archive]]

Djst at 12:47, 6 October 2009

2009-10-06T12:47:10Z

← Older revision		Revision as of 12:47, 6 October 2009
Line 211:		Line 211:
	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.		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.

	=~~Related~~=		=Decision=
	[[Support/TikiUpstreamPlanning]]		We will go with the Upgrade option and upgrade to TikiWiki 4.1 or 5.1 in early 2010. See [[Support/TikiUpstreamPlanning]]

MarcLaporte at 00:09, 3 October 2009

2009-10-03T00:09:32Z

← Older revision		Revision as of 00:09, 3 October 2009
Line 210:		Line 210:

	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.		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.

			=Related=
			[[Support/TikiUpstreamPlanning]]

MarcLaporte: /* Upgrade */ Morgamic, Laura, James, David, Paul

2009-09-26T02:40:53Z

Upgrade: Morgamic, Laura, James, David, Paul

← Older revision		Revision as of 02:40, 26 September 2009
Line 29:		Line 29:
	***[[Support/UpgradeToTiki4/ThemeCoordination]]		***[[Support/UpgradeToTiki4/ThemeCoordination]]
	***Live at: http://sumo.ourwiki.net/		***Live at: http://sumo.ourwiki.net/
	*3 SUMO developers have commit access to Tiki trunk, and all is needed is a SourceForge username to have more :-)		*[http://sourceforge.net/project/memberlist.php?group_id=64258 5 SUMO developers have commit access to Tiki trunk], and all is needed is a SourceForge username to have more :-)

	'''Cons'''		'''Cons'''

Djst: /* Notes from David */

2009-09-25T08:43:17Z

Notes from David

← Older revision		Revision as of 08:43, 25 September 2009
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.

Djst: /* Notes from David */

2009-09-24T21:26:17Z

Notes from David

← Older revision		Revision as of 21:26, 24 September 2009
Line 207:		Line 207:
	*** [Ongoing] Upstreaming of future patches		*** [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.		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.

Djst: /* Notes from David */

2009-09-24T15:51:36Z

Notes from David

← Older revision		Revision as of 15:51, 24 September 2009
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 ~~upstreaming~~ of patches ~~for future bug fixes (not including the bugs in the initial upgrade)~~		*** [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.

Djst: /* Notes from David */

2009-09-24T15:50:03Z

Notes from David

← Older revision		Revision as of 15:50, 24 September 2009
Line 194:		Line 194:

	===Notes from David===		===Notes from David===
	Here's my attempt to distill the main points ~~you're~~ making and respond to them one by one:		Here's my attempt to distill the main points James is making in "proposal 2" 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		* Upgrading gives very little concrete benefit [...] the only concrete benefit that we would actually use is the migration PDO

Djst: /* Notes from David */

2009-09-24T15:49:26Z

Notes from David

← Older revision		Revision as of 15:49, 24 September 2009
Line 199:		Line 199:
	** Based on Laura's list above, PDO is far from the only benefit		** 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 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.		** I think the main speculation here is that we'll benefit from increased participation (or participation period) from the Tiki community if we start to work more closely with them. However, based on the e-mails received the last few weeks from people like Marc, Stephane Casset, Alain Desilets, luci, and Gary, I would argue that it's not just speculation -- participation from Tiki actually started to happen 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		*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:

Djst: /* Notes from David */

2009-09-24T15:40:35Z

Notes from David

← Older revision		Revision as of 15:40, 24 September 2009
Line 201:		Line 201:
	** 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.		** 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		*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 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)		*** 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 coordination/communication with the Tiki community to ensure that our refactoring doesn't break other sites