[TYPO3-core] Change procedure revisited

[François Suter]

Hi,

>> So it depends on the patch, sometimes it's a matter of minutes and you
>> (the commiter) can just "do it" (cherry-pick and merge), sometimes it
>> involves testing in older branches, and you (the commiter) might not
>> feel like doing it (at least right away).
>
> 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 
postpone back-porting because I did not have enough time at a given 
point in time, and it seemed like a shame not to submit just because I 
didn't have time to back-port. But of course that could be a requirement 
and would change our submission policy.

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.

I know this is probably quite tricky to solve, but it would be hugely 
useful IMO.

Cheers

-- 

Francois Suter
Cobweb Development Sarl - http://www.cobweb.ch