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

[Gerald Combs <gerald () wireshark org>]

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.quantin () gmail com>:
> > 2014-03-31 23:17 GMT+02:00 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.
> >
> >
> > 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-request () wireshark org?subject=unsubscribe