[TYPO3-core] Change procedure revisited
François Suter
fsu-lists at cobweb.ch
Tue Nov 22 11:52:12 CET 2011
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
More information about the TYPO3-team-core
mailing list