With both 4.8 and 5.0 in gerrit, how should we do back/forward porting of bug 
fixes between repositories?
Should the change author cherry-pick, resolve conflicts, and submit a change to 
the other repository?

Or will a fix accepted to 4.8 be applied to 5.x without usually needing further 
involvement of the author?
(like the 4.7->4.8 merges, although it probably can't be done with a git merge)

I'd assume the author knows best how to resolve conflicts, but it raises the 
bar for entry.

My view is the workflow should look like this:

1. author submits change to the version they normally work on (4.8 or 5.0)
2. code review happens, change accepted
3. CI happens, change integrated
4. author cherry-picks to the other repository, resolving any conflicts & test 
on their preferred platform
5. code review - if there weren't conflicts then this should often be a 
formality by the previous approvers
6. CI happens - this will pick up if the change isn't compatible with the 
new/old architecture. (if the reviewers missed it)

My experience is that cherry-picking QtCore and QtNetwork changes is usually 
OK, except for autotests which conflict due to path changes

________________________________
Subject to local law, communications with Accenture and its affiliates 
including telephone calls and emails (including content), may be monitored by 
our systems for the purposes of security and the assessment of internal 
compliance with Accenture policy.
______________________________________________________________________________________

www.accenture.com

_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to