On 3/27/14 10:13 PM, Anders Broman wrote: > Hi, > How do we handle backports in the new work flow with git? The submitter > of a patch could help > by submitting the backport once the patch has been accepted. But what do > we do in the case > when this isn't happening? The core developer accepting the patch might > not have the time/don't want > the extra work of making a backport.
Prior to the Git migration the Roadmap page was effectively a dumping ground for merge conflicts. I'd end up processing the queue a day or so before each release which didn't leave much time for testing or validation. I would very much like to avoid going back to that. If there aren't any merge conflicts you can cherry-pick a change using several methods: - "git cherry-pick" - The "Cherry Pick To" button in Gerrit's web interface - The "gerrit-cherry-pick" script: https://code.wireshark.org/review/Documentation/cmd-cherry-pick.html - git-review's "-x" flag For each cherry-pick the release notes need to be updated with any bug fixes, protocol updates and (if needed) an advisory. This can be done by amending or with a separate commit. I don't think this is documented anywhere but I can add instructions to the wiki and/or the Developer's Guide. If there are merge conflicts someone needs to decide if the backport is worth the effort of resolving the conflict. Again, I would prefer that this happens as early as possible. ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
