[TYPO3-core] Change procedure revisited

[Ernesto Baschny [cron IT]]

François Suter schrieb am 22.11.2011 13:17:
> Hi,
> 
>> 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.
> 
> Sure but I wouldn't push a patch which I haven't tested myself. Of
> course that's maybe just a personal thing.

I guess that should be the rule. You push to our v4 core official
branches only tested and validated stuff and not "work in progress" or
automatic backports that are not really tested or at least thought through.

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

> Indeed, but it's set automatically in Forge when the patch is merged in
> Gerrit. That's what should be improved.

I think there is work in progress on that matter, although it seems to
be difficult to tackle. To quote Steffen Gebert (16.11.2011): "The issue
is closed by Redmine itself, as soon as it updates its Git working tree
and finds a commit referencing an issue."

So it would require some "redmine hacker" to implement the
differenciated policy to only close if it is merged in all relevant
branches (and redmine has to know that "4.7" is "master" etc).

Maybe implementing it from "remote" and setting the status via a REST /
SOAP call instead would be more bullet easy to tackle.

Please continue the follow-up to this in #27405 [1], as I proposed this
idea there now.

Cheers,
Ernesto

[1] http://forge.typo3.org/issues/27405