On 4/2/14 4:25 AM, Bálint Réczey wrote: > Hi Gerald & All, > > 2014-04-01 2:41 GMT+02:00 Pascal Quantin <pascal.quan...@gmail.com>: >> 2014-03-31 23:17 GMT+02:00 Gerald Combs <ger...@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. >> >> >> Hi Gerald, >> >> what about using the old wiki page to list the bigfixes candidates for >> backport but not done yet? This could help (temporarily) people not >> confident yet with the new backport procedure (even if git cherry pick >> command makes it much less error prone than subversion). >> BTW sorry for not updating the release notes with my backports (it was not >> documented afaik). > I think this partial resurrection of the old wiki page would be a wise > idea. It also listed the expected date of next release which would be > still useful.
Done. (I wasn't intending to kill the RoadMap page entirely. No one updated it after the 1.10.6 / 1.8.13 releases.) > IMO it would be better to update the documentation when right before > the release instead of with every commit because it would make > cherry-picking changes easier (like master -> master-1.10 -> > master-1.8, etc). There goes my plans for laziness. :) ___________________________________________________________________________ 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
