[TYPO3-core] Change procedure revisited

[Xavier Perseguers]

Hi,

>> 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
POV.

> 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.

Yes.

> 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