If you have finished changing the Wireshark sources to suit your needs, you might want to contribute your changes back to the Wireshark community. You gain the following benefits by contributing your improvements:
There’s no direct way to push changes to the Git repository. Only a few people are authorised to actually make changes to the source code (check-in changed files). If you want to submit your changes, you should push them to the code review system.
Some tips that will make the merging of your changes into Git much more likely (and you want exactly that, don’t you?):
git diffand make sure you aren’t adding, removing, or omitting anything you shouldn’t.
In general, making it easier to understand and apply your patch by one of the maintainers will make it much more likely (and faster) that it will actually be applied.
Wireshark is a volunteer effort. You aren’t paying to have your code reviewed and integrated.
The core maintainers have done a lot of work fixing bugs and making code compile on the various platforms Wireshark supports.
To ensure Wireshark’s source code quality, and to reduce the workload of the core maintainers, there are some things you should think about before submitting a patch.
|Pay attention to the coding guidelines|
Ignoring the code requirements will make it very likely that your patch will be rejected.
Submit dissectors as built-in whenever possible. Developing a new dissector as a plugin is a good idea because compiling and testing is quicker, but it’s best to convert dissectors to the built-in style before submitting for checkin. This reduces the number of files that must be installed with Wireshark and ensures your dissector will be available on all platforms.
This is no hard-and-fast rule though. Many dissectors are straightforward so they can easily be put into "the big pile", while some are ASN.1 based which takes a different approach, and some multiple sourcefile dissectors are more suitable to be placed separate as plugin.
Verify that your dissector code does not use prohibited or deprecated APIs. This can be done as follows:
$ perl <wireshark_root>/tools/checkAPIs.pl <source filename(s)>
When you’re satisfied with your changes (and obtained any necessary approval from your organization) you can upload them for review. Changes should be pushed to a magical "refs/for" branch in Gerrit. For example, to upload your new Snowcone Machine Protocol dissector you could push to refs/for/master with the topic "snowcone-machine":
$ git push ssh://[email protected]:29418/wireshark HEAD:refs/for/master/snowcone-machine
You can push using any Git client. Many clients have support for Gerrit, either built in or via an additional module.
You might get one of the following responses to your patch request:
You don’t get any response to your patch. Possible reason: All the core developers are busy (e.g., with their day jobs or family or other commitments) and haven’t had time to look at your patch. Don’t worry, if your patch is in the review system it won’t get lost.
If you’re concerned, feel free to add a comment to the patch or send an email to the developer’s list asking for status. But please be patient: most if not all of us do this in our spare time.