> On 24 Jan 2019, at 14:15, Jedrzej Nowacki <jedrzej.nowa...@qt.io> wrote: > > Typical use case I have with bug fixing in dev is when I develop a feature > and > I see let's say a memory leak in the code that I'm modifying or somewhere > around. With the merge model I have four options now: > 1. Pretend that I haven't seen it > 2. Make a fix in LTS and develop my feature separately, counting on the merge > master to resolve conflicts > 3. Do the fix only in dev > 4. Make a fix in LTS and wait for all merges before I continue with the > feature > If it is a memory leak then it is not as bad as memory corruption and > crashes, > as at that point I can not use approach 2. Option 1 and 3 are not great from > QA perspective. Option 4 is slow and kills motivation for development.
5. Ask Liang to do a merge ASAP, as soon as the LTS fix is integrated 6. Do the merge yourself on dev, push it, add reviewers, and in the meantime, develop your feature on top (but so far we have a cultural limitation on who is allowed to do this) 7. Cherry-pick the fix patch on dev so that you can keep working. After that: 7a. Periodically run git pull —rebase locally until the rebase pulls in the merged fix, and your new changes are now on the tip; by then, nobody can see that you did the cherry-pick; or, 7b. Push both patches, with the cherry-picked fix marked WIP and with a note that it’s a temporary cherry-pick, so that nobody will try to review or integrate it (or write redundant comments reminding you that you shouldn’t do that). This way you can get your new work reviewed: you just can’t stage it until the merge is done (and then you can abandon the cherry-picked fix). _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
