[TYPO3-core] RFC 17978 -.... 30% performance drop without discussion

[Christian Kuhn]

Hey.

On 02/06/2013 08:31 PM, Tolleiv Nietsch wrote:
> Thanks for your answer - this doesn't answer my question. Why does this
> have to be merged without proper measurements done by multiple people
> and why don't we use a  dedicated branch for these changes until we gain
> back the "original" performance? What's so urgent here?


There are lots of reasons not to develop things in a sandbox:

* We've made the experience that (especially big) sandbox or github 
forks do not tend to get ready at all.

* Big work-in-progress things are hard to maintain and need to be 
rebased very often. This patch had to be rebased two times even during 
the short time frame it was pending.

* Rebasing can introduce bugs and adds complexity, for example because 
related code was changed meanwhile.

* Merging big things to master again is a lot of work: If done right, it 
must be split into several single patches and every single patch needs 
patch sets until everyone is happy, which means even more rebasing for 
patches that depend on each other. If done wrong, it will be only one 
big patch, or a series of big patches which makes them just 
un-reviewable. We've had this situation with FAL, and there are still 
really heavy bugs like https://review.typo3.org/#/c/17588/ Chances are 
lower that those things happen if taking smaller steps. Chances are 
higher that issues pop up and fixed more early if things are already in 
master.

* I tend to introduce more bugs and forget about details if I do not get 
every single patch review ready, just because I'm already working on the 
next part of, with a mindset "Well, its just my sandbox, I can clean up 
details later on".

* It is more effective to work in single steps and merging them to 
master in steps than working on own stuff in a sandbox for a long time: 
Changes are higher that other people step in for help. Very good example 
for that was the namespace merge: After the initial big merge (which had 
to be done in master directly, too, we even had a merge freeze dedicated 
for this), we've had more than 100 patches (I did not look up exact 
numbers, but it was huge) quickly going through to fix things. They came 
from a large group of contributors.

* It is much more motivating to have small feelings of success more 
often because single things are done.

* It is very well possible that the "do not always load all ext_tables" 
approach in FE might be re-implemented later on because for example our 
ideas did not work out, or are not finished. But, the solution will be 
different and better. I'd for example never ever under no circumstances 
re-implement the TCcachedExtras thing or the includeTca method again 
this way. So, we *might* end up with a similar solution again, but it 
will still profit from the improved code and other changes that happened 
afterwards. And there will be a larger group of people who understand 
the details for further improvements because they did the reviews and 
followed the other patches in this area.

* Release early and often.


As only drawback, working directly in master so much with lots of 
on-top-of-patch-patches needs quick merges, otherwise you are quickly 
stuck, or you are in rebase hell all the time. I'm extremely happy there 
is a group of active reviewers and contributors around, getting things 
done and helping each other.
BIG thanks to our active people, it is great to works with you!


Regards
Christian