[Development] Cherry picking to replace a change set

[Samuel Gaist]

On 31 août 2013, at 23:37, Thiago Macieira wrote:

> On sábado, 31 de agosto de 2013 21:24:21, Samuel Gaist wrote:
>> Just to be sure (for a future work),for example
>> https://codereview.qt-project.org/#change,63526 and 
>> https://codereview.qt-project.org/#change,63699 that try to fix Bug-1180.
>> The bug applies to both 4 and 5. But in Qt5 the same fix also uncovered
>> another problem that I tried to address within the same patch set. So the
>> correct work flow would have been to first fix all the problems in Qt 5,
>> cherry pick and only apply and submit the needed changes to Qt 4 ?
> 
> The correct work flow would have been to have one commit that does one thing 
> only. Then you could have cherry-picked it in its entirety.
> 

Just thought about something: Is it possible to have some sort dependency between two commits in jira ?

My example shows exactly the problem of one fix common to Qt 4 and 5 that reveals another bug (in Qt 5 but not 4) that must be solved first in order to have a "clean solution".

So currently (from my limited knowledge), I see three possibilities:
- Both fix in the same patch (not atomic but everything is fixed in one go)
- Send the second fix, wait for it to be integrated and then submit the first one (atomic but not necessarily efficient)
- Send both separated and "self -1" the commit that needs to wait for integration and add a comment stating the needs for the other to test/validate the solution (again atomic but not necessarily efficient, on the plus side people wanting to do tests have all the changes needed)

Option 2 and 3 allow for a clean cherry pick to Qt 4 but might slow down the integration of the complete fix in Qt 5 so...

What would be the best workflow in this case ?