Re: Backporting policy for protocols that are under construction

[Roland Knall <rknall () gmail com>]

Hi

The original argument for the backport was not so much the implementation
of a new feature, but rather the removal of a never used feature and
implementation of the actual used feature instead. I agree that the
development branch is very stable, but at the same time, many people prefer
to use the official releases. And for them our protocol would seriously
break until Wireshark 2 will be released. I am ok with a decision either
way.

regards,
Roland

On Thu, Nov 20, 2014 at 1:29 PM, Bálint Réczey <balint () balintreczey hu>
wrote:

> Hi,
>
> 2014-11-20 12:05 GMT+01:00 Alexis La Goutte <alexis.lagoutte () gmail com>:
> > On Thu, Nov 20, 2014 at 5:03 AM, Evan Huus <eapache () gmail com> wrote:
> > > There is currently a change pending backport to the 1.12 branch (long
> > > since committed to master) that is a non-trivial dissector upgrade.
> > > Normally we don't backport this kind of change, to keep the regression
> > > potential to a minimum for stable releases, but this situation is
> > > somewhat unusual. The protocol in question was still being actively
> > > designed and developed when the 1.12 branch was created, so the
> > > dissector currently in the 1.12 branch implements a basically
> > > abandoned version of the spec that never ended up in serious use.
> > >
> > > I am ambivalent on this right now. I don't want to cause too much
> > > churn on the stable branch, but I can see the argument for backporting
> > > it regardless. It's also worth noting that while the protocol in
> > > question now is relatively narrowly focused, we will likely run into
> > > the exact same issue soon with HTTP2 which is rather more significant.
> > >
> > > What does everyone think? Should we be conservative and forbid this
> > > sort of thing? Permit it, but only after some extra level of
> > > testing/review? Other options?
> > >
> > > Thanks,
> > > Evan
> > >
> > > (The change in question is https://code.wireshark.org/review/4050 but
> > > I'm kind of looking for a more general resolution given that we're
> > > going to run into this problem again.)
> >
> > My opinion :
> > When it is some "minor change" and don't need add/change a lot of code
> > (< 250 lines ?), it will be ok
> > Avoid to add/change some new header field (hf)
> >
> > in case of HTTP2, i waiting the final draft to backport fix (to be
> > sure there is no new frame change...)
> > When final draft will be available, will be no longer need a support
> > of old draft (all implementation follow quicky the change on HTTP2
> > spec)
> >
> > About https://code.wireshark.org/review/4050
> > tfs change will be remove (it is a enhance for me), and also don't
> > remove the if 0 (only add stuff for support last change)
> Since our development builds are of very good quality people living on
> the bleeding edge can use them without any problem.
> I would prefer back-porting only very small and very important bug
> fixes and no features because every back-port makes back-porting other
> changes harder.
>
> Cheers,
> Balint
> ___________________________________________________________________________
> 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
___________________________________________________________________________
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