Contributing
First of all, all development happens within in the development branch.
I tend to modify this thing pretty sloppily, so I figure by adding broken
things to a different branch this might improve stability or something.
When you submit a pull request, please submit it against this branch as
this branch will eventually be merged into master.
If you're unsure of something or the documentation isn't clear, feel free to create an issue and someone will try and help you figure it out.
Of course, search the current issue list to see if someone else has already reported it. Typically I'll self-report issues, but who knows.
When creating an issue be sure to include the version of IDA you're using, the platform it's running on (32-bit or 64-bit), the architecture of your database, and whatever code you're running that doesn't work. Pretty straight-forward...
When submitting a pull request, keep in mind about what version of IDA
your PR doesn't work on as this plugin needs to be backwards compatible
with IDA 6.9 (before the idaapi modules were split up). If your
addition does not support IDA 6.9, please make sure you mention it in
the details when you submit your PR.
Another thing to keep in mind is which module (or context) your addition is for. If it warrants a new base module, please mention it and we can discuss what the best way to do this might be.
The last thing to note is keep in mind how multicase functions work. If you're not sure of what these are, please refer again to documentation. If you're adding a new function, try and consider what other types your function might be able to take, and how many ways a user can get to those types.
Again, if you're not sure. Submit the PR to start a discussion, and we can discuss what other requirements there might be.
If you're still working on a pull request, you can prefix the title of your pull request with "[WIP]". This will notify any committers that your PR is still in development. When you're ready for it to be merged, remove the prefix or mention it in the discussion and after it's reviewed, it will likely get merged.
When titling the pull request, prefix it with either the module you're modifying or if it's in the root directory, include the full filename.
As an example, the base/database.py module might have a title of:
base/database: added blah blah function
Another example, say for idapythonrc.py could be:
idapythonrc.py: added support for external plugins
This should result in much better looking (and easier to follow) commit logs than the author's.
The docs branch contains the current state of documentation for this
plugin. Each module's documentation is actually generated by the
docs/docparse.py file based on some magic decorators in the
base/_document.py module.
This means other than the static documentation in docs/static, the
documentation for each function and its parameters will need to be
modified within the module that actually contains it.
If something on there is badly documented or is missing for some crazy reason, please prefix your PR title with "docs/" and follow the same method as described in "Titling pull requests". If you've updated the documentation for "matching.rst", then title it like:
docs/matching: fixed some really bad english
Or if it's some documentation in a specific module such as
base/instruction.py:
docs/instruction: fixed the spacing for the module autodocs
The reason being is that any modifications to the documentation's
autodocs will need to be backported into the master branch. This
"docs/" prefix will notify me that it needs to happen.
The following pull requests are desired:
- Pull requests that introduce new architecture (registers or operands)
- Bug fixes (I did a lot of refactoring to get this to a release point. There's a chance I broke some things, but who knows).
- Documentation fixes
If a new version of IDA gets released and for some reason parts of the plugin do not work, please open an issue and report it. This plugin aims for backwards compatibility with all "known" versions of IDA.
Thanks for your interest in contributing to this plugin!
|
|