Blocker, by definition, means it blocks development or testing. That
bug is likely giving me hell with a dissector I've been writing for
work. At work we classify bugs as: blocker blocks development, testing,
or use of the feature. Critical is crash/hang. Major is loss of
functionality without a reasonable workaround. Normal is loss of
functionality with a reasonable workaround. The classification here
seems to be roughly the same.
I think if you twist the words enough, you could claim (with a
straight face) it's a blocker: it blocks you from testing with certain
types of tcp packets.
-Brian
John R. wrote:
On 10/9/06, Joerg Mayer <jmayer@xxxxxxxxx> wrote:
On Mon, Oct 09, 2006 at 04:08:04PM -0700, Gerald Combs wrote:
I'd like to release 0.99.4 next Wednesday (the 18th). If you're
planning on checking in any major changes, please hold off until the
release branch is created (probably Friday or Monday).
Hmm, there are still some open points on the roadmap:
Pending:
Version checking.
Windows updater.
Fix Coverity bugs.
Fix blocker bugs:
396 - Saving flow data crashes Wireshark
Finish capture privilege separation.
Use the "User's Guide" as the online help system for Wireshark releases
So does this mean only blocker bugs are fixed in the short term?
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1124
Seems pretty important since it means that in circumstances where
packets are split across tcp segments there are significant issues
with desegmentation and dissection, probably across all application
layer protocols on top of TCP where PDU length is judged by header
rather than trailer data. Is Severity of Major the right thing or not?
I suppose it's not a crash/hang bug so it ain't an emergency but I am
curious how bugs are prioritized for fix.
Thanks,
-- John.
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
