Hi, 2014-11-20 12:05 GMT+01:00 Alexis La Goutte <[email protected]>: > On Thu, Nov 20, 2014 at 5:03 AM, Evan Huus <[email protected]> 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 <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
