Patch and feature approval strategy


(Markus Bischof) #1

Hi there,

since I’m a little bit frustrated at the moment because of the translation handling fiasco (e.g. https://forge.typo3.org/issues/80855 or https://forge.typo3.org/issues/62921) I want to write some lines here.

I love the concept of Open Source and I was (some time ago) not a big fan of how the linux kernel is managed (one final instance which decides if some changes make it into the kernel or not).

Meanwhile (after I spent hours and hours to track down problems in the TYPO3 CMS core) I changed my mind. Wouldn’t it be a good idea if there is one person (or handful) who have real good knowledge of the whole TYPO3 CMS ecosystem at the top who decides if a patch/feature goes into the system or not.

Maybe the quality of the TYPO3 CMS project would benefit from such an approach.

From my point of view TYPO3 CMS should be a framework for developers to help them bringing new system to life “quick and easy”. At the moment I think we (or at least I) do more core debugging than coding at the real task.

What do you think?


(Georg Ringer) #2

I don’t really know how the situation you want to have differs from the current situation. There is the core team and others who have this knowledge about the core.
However those are not the only one who decide what should be tackled next but also the ones who code the feature which can of course also be you, your company or you and a friend. The core team will always try to help.

As always problem is time of the ones who are active as there is daily life, jobs, family, and so on.

If you want current bugs to be solved, get active, collect money with others who need the solution as well, talk to the core team and others at events,…


(Markus Bischof) #3

It’s not about getting current bugs fixed. It’s about doing right. For example: as far as I understood the discussion in https://forge.typo3.org/issues/62921 there is code in the core system which is not correct - and this is not only case.

Because of that I thought it would be a good idea to have someone at the end of a patch/feature workflow who has the knowledge to decide if this new feature or patch break something.


(Kevin Ditscheid) #4

As far as I understand, you want a system like the current one, where there need to be positive reviews of patches to be integrated into the main line of the TYPO3 master. This is provided already by the review System - I think it’s gerrit - and by the automatic testing framework, which does positive or negative reviews on patches, depending on if it runs through or throws errors.
I don’t know much about the issue you are working on, but I heard about the whole topic of IRRE translations being quite complicated and many solutions do not take other needs to the handling into account.
So, I think the current system is very much a good one, but naturally it is taking efford and time for such a huge project like TYPO3 and in every software project there can be bugs unseen by many reviewers.


(Susi Moog) #5

The current system for core changes consists of:

  • a core team leader and co-leader - leader has the last word on any change (and both have many, many years of experience both with TYPO3 as with web technology / projects in general and IMHO are really well-suited for the job)
  • a product team for organizational / long-term team “management”
  • a core team with < 30 people that are allowed to merge patches into the core
  • a review system which requires at least one testing and one code-review vote from a core team member and another code-review and test by someone else - for bigger patches almost always more than these are actually done.
  • a continuous integration system running unit, functional and acceptance tests before any merge on various different configurations (for example different PHP versions, mysql vs postgres etc.)

So basically as far as I understood, what you want is there already.

On to the topic of your examples: Yes, there is definitely code in the core that is not correct - which is basically the description of any bug and there are known bugs in TYPO3. Especially the area of multi-language, nested records, fallbacks etc. is extremely complex, as the expected behaviour is not always clear to everyone (as different people sometimes just have different use cases), the code base is somewhat older and every iteration has to be at least “migratable” from the previous version, the amount and of people willing to dig in those areas is really small and the complexity very high at the same time. If you want to contribute to solving these kinds of issues, it boils down to sponsor or provide active development in these areas - but be prepared, that just understanding these parts of the core (not only code-wise, but simply logic wise) will take a lot of time. Another thing people could do to help would be to test patches with their use cases (or at least test the sprint releases) because the core team will never be able to foresee any use case in the world.


(Dmitry Dulepov) #6

My two cents: it would be nice to have areas of expertise for the core and require approval from a person, who is an expert in the area. Sometimes people just approve the code because it looks good but they are not experienced enough in the areas that they approve. This is the cause of the problem.


(Markus Bischof) #7

This is exactly what I mean.


(Frans Saris) #8

This is already in place, before a core team member approves a patch he/she should have consulted the domain expert about this if he/she isn’t the domain expert. But maybe we should make it visible for everyone what part of the core every core team member has his or hers expertise


(Markus Bischof) #9

Should have consulted sounds like an optional task to me. Who defines which persons are domain experts?


(Markus Klein) #10

Mostly being the author of the biggest code parts.
At least I’m not aware of any other means.


(Frans Saris) #11

There are some guidelines about this topic, see https://typo3.org/teams-committees/core-development/roles-groups/


(system) closed #12

This topic was automatically closed after 28 days. New replies are no longer allowed.