[TYPO3-core] Change procedure revisited

Xavier Perseguers xavier at typo3.org
Tue Nov 22 12:06:27 CET 2011


>> I'd say that *at least* the committer should cherry-pick and push to
>> Gerrit. This takes no time at all!
> That would be ideal, but depending on the patch, back-porting may not be
> so trivial, as you need to test it again, which may imply some effort in
> order to reproduce the conditions for the bugs. I guess this is why the
> back-porting is sometimes neglected. I know it happened to me to

This is why I said "pushed" and not "merged". You always can push a
backport and if you don't merge it (you may even add a comment), it
sounds like it should be reviewed the standard way... At least that's my

> On the same topic, but different idea: it would be great if a Forge task
> could be not marked as resolved until the patches have been submitted to
> *all* branches.


> I don't know how you manage that as a RM. For example take the list you
> recently submitted of open bugs for 4.6.1. Such a list has 2 problems:
> 1) it does not take into account bugs which are targeted at 4.4 or 4.5
> (because we always target the lowest branch)
> 2) if the issue is target at 4.6.1 and the master patch has been merged,
> the issue is marked as resolved and thus does not appear as pending for
> 4.6.1. I know that's where Ernesto's script may help, but it implies an
> extra step to check and people may not even think about checking if they
> base themselves on a simple list of open issues for 4.6.1.

As long as the bug is not merged into all branches, it should not be set
to resolved.

Xavier Perseguers
Release Manager TYPO3 4.6

TYPO3 .... inspiring people to share!
Get involved: http://typo3.org

More information about the TYPO3-team-core mailing list