[Development] When is Qt 4.8 in Gerrit? (Was: Qt Commercial 4.8.0 release delta to LGPL version)

shane.kearns at accenture.com shane.kearns at accenture.com
Tue Jan 10 12:57:35 CET 2012


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




More information about the Development mailing list