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 <[email protected]> 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 <[email protected]> > wrote: >> >> 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 > > > > ___________________________________________________________________________ > 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 ___________________________________________________________________________ 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
