Re: What about backporting fixes to older releases with the new workflow?

[Gerald Combs <gerald () wireshark org>]

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-request () wireshark org?subject=unsubscribe