It's perfectly okay to log an "enhancement" in Bugzilla, just mark the bug as such. It would also be a logical place to store a sample capture that exercises the new functionality of the dissector in question.
If you think the functionality will take multiple commits, add "Ping-Bug:xxxx" (the number assigned to the bug once it's submitted) as the last line in your commit message (just above the Change-Id). For your "last" (or only) commit that finishes the functionality, add "Bug:xxxx" to the last line of the commit, then Gerrit can automatically tell Bugzilla to just close the bug.
-----Original Message-----
From: Alan Partis <alpartis@xxxxxxxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Sent: Sat, Jan 23, 2016 11:44 am
Subject: [Wireshark-dev] bugzilla qualification
What is the feeling amongst the development team regarding what should be
reported in the wireshark bug db, and what should not?
Specifically, I'm doing work on a particular dissector that does not yet
support certain features of its protocol -- I'd like to document the
needed upgrades via bugzilla so I can reference those reports in the
related commit messages. This way, others who want to track the progress
of what is, and is not yet, supported in the dissector, can do so the the
bugzilla reports as opposed to having to get the code and examine it to
see what's NOT there.
What say you all?
_______________________________________________________
Alan Partis
thundernet development group
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <
wireshark-dev@xxxxxxxxxxxxx>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
