Wireshark mailing list archives
Re: Backporting policy for protocols that are under construction
From: Evan Huus <eapache () gmail com>
Date: Mon, 24 Nov 2014 21:37:55 -0500
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 () gmail com> 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 () 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
___________________________________________________________________________ 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
Current thread:
- Backporting policy for protocols that are under construction Evan Huus (Nov 19)
- Re: Backporting policy for protocols that are under construction Alexis La Goutte (Nov 20)
- Re: Backporting policy for protocols that are under construction Bálint Réczey (Nov 20)
- Re: Backporting policy for protocols that are under construction Roland Knall (Nov 20)
- Re: Backporting policy for protocols that are under construction Evan Huus (Nov 24)
- Re: Backporting policy for protocols that are under construction Bálint Réczey (Nov 20)
- Re: Backporting policy for protocols that are under construction Alexis La Goutte (Nov 20)