Support/TikiWikiUpgrade: Difference between revisions

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.
1,623

edits