Given the lack of other responses (I guess most people don't have a
strong opinion) I'm going to lean conservative and agree with Balint.
I'm happy to revisit if anybody else has strong feelings on the
matter.
On Thu, Nov 20, 2014 at 7:35 AM, Roland Knall <rknall@xxxxxxxxx> wrote:
> 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@xxxxxxxxxxxxxxx>
> wrote:
>>
>> 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
>>
>> ___________________________________________________________________________
>> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>> Archives: http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>
>> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>
>
>
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe