[TYPO3-dev] Are performance improvements part of maintaince releases?

Ingmar Schlecht ingmar at typo3.org
Fri Jun 26 09:02:52 CEST 2009


Hi guys,

thanks for all your comments on the issue.

For this patch, Ingo has finally decided not to let it into the 4.2
branch, due to the reasons he explained earlier.

To avoid such long discussions in the future, I propose:

  - [internally] to discuss this at the next core team meeting and make
    up some general rules regarding such improvements, possibly based on
    Lars' suggestion

  - to always ask the release manager *before* committing something to
    the stable branches that doesn't look like a bug fix, so things like
    reverting a patch is not necessary

cheers
Ingmar


Rupert Germann wrote:
> hi,
> 
> again:
> Are performance improvements part of maintaince releases?
> 
> or in other words: 
> is a function that makes 50 identical sql requests when rendering a page a
> bug?
> 
> the last discussions about this questions in the core list showed that we
> don't have a consensus on this issue.
> 
> Current cases:
> http://lists.netfielders.de/pipermail/typo3-team-core/2009-June/027147.html
> http://bugs.typo3.org/view.php?id=11358
> 
> http://lists.netfielders.de/pipermail/typo3-team-core/2009-June/027185.html
> http://bugs.typo3.org/view.php?id=11317
> 
> the reasons for reverting 11358 and for preventing 11317 from being applied
> to the 4_2 branch are:
> (wildly citing from these 2 threads)
> - "performance tuning is not part of maintainance releases."
> - "There is no urgent need to improve the performance. It's just nice to
> have."
> - "the risk to break something is always higher than without a patch"
> - "...I think we had some problems earlier with similar kinds of caches,
> which produced unexpected results in some scenarios..."
> 
> OK, we have a release-workflow document but it doesn't say anything about
> performance improvements:
> http://typo3.org/teams/core/resources/release-workflow/
> 
> so argument 1 seems to be pointless. or I have overlooked something?
> 
> next point states that performance improvements are only a "nice-to-have"
> thingy. Hmm, ok, matter of taste for some people, maybe. But what about the
> people for them performance is a bit more crucial thing? holding back
> performance related fixes in maintaince versions seems to ignore them and
> their needs.  
> 
> and point 3 and 4 say that adding a patch could possibly break something.
> uhmmm, yes that's true, indeed. We are humans and humans make mistakes
> (remember 4.2.4). But is not adding obvious improvements a solution for
> this problem?
> 
> Dudes, are we core-devs or are we sissies?! ;-)
> 
> We know what we are doing. 
> We are able to say that adding a few lines of code that prevent a function
> from bothering the database with 50 identical queries will NOT break
> anything. We only have to read and test the code. 
> 
> And we're also able to say that enhancing TYPO3 4.2.x by a cache for an
> expensive function which has been tested for almost a year now in TYPO3 4.3
> will not break anything.
> 
> and while we are on it: 
> let's also talk about other improvements in current (stable) versions. what
> about this:
>  
> 2009-06-02  Steffen Kamper  <info at sk-typo3.de>
>         * reverted #9849 as this wasn't present in 4.2.0
>         * Fixed bug #9849: edit-wideDocument was removed, bring it back
> (from 4_2 branche changelog)
> 
> dropping "edit-wideDocument" was a bug! no question !
> Will there be no chance to fix usability errors once the xx.0 version is
> out?
> 
> 
> let the flamewar begin 
> 
> 
> 
> greets
> rupert
> 
> 
> 
> PS: at the end of this discussion I'd like to see a document which clarifies
> which improvements are bugs and which are not.
> 
> 




More information about the TYPO3-dev mailing list