Home page logo

wireshark logo Wireshark mailing list archives

Re: What about backporting fixes to older releases with the new workflow?
From: Gerald Combs <gerald () wireshark org>
Date: Mon, 31 Mar 2014 14:17:41 -0700

On 3/27/14 10:13 PM, Anders Broman wrote:
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:
- 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

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

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]