Wireshark-dev: Re: [Wireshark-dev] Backporting policy for protocols that are under construction
Hi,
2014-11-20 12:05 GMT+01:00 Alexis La Goutte <alexis.lagoutte@xxxxxxxxx>:
> On Thu, Nov 20, 2014 at 5:03 AM, Evan Huus <eapache@xxxxxxxxx> 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
