|
|
||
Contribute to Blink!
Blink is an open-source project. Anyone should be able to contribute if they want a new feature implemented. The only requirement for the code to be accepted is to be well written and maintainable. If someone needs a feature that's important to them but it's not on our roadmap, they can contribute it.
The decision if something will be included in the official repository is based on:
- How useful a feature is for other people.
- The code that adds the feature must be well designed. The design should be clean, simple and self contained, avoiding complex dependencies on other parts of the code as much as possible. The code should be self documenting (well named classes, methods, variables that help understand what they intend to do without resorting to comments or external documentation).
- The code must follow the coding conventions already in place in blink, regarding naming conventions, spacing, etc. We mainly use python's pep8 for our coding style in python and pep7 for the C code in case there is a python extension involved. They are available here:
Is good to discuss the design first on the mailing list so that the best approach is found to avoid multiple costly iterations later. Also follow the coding style in order to avoid similar multiple iterations before the code is admitted.
Documentation
If you wish to contribute to Blink you must first identify whether there is a need to change the underlying Protocols Layer or the GUI.
The Protocols Layer is described in the Middleware API section of SIP SIMPLE client SDK. You must consult the SDK Support Page for how to submit a patch.
The GUI is the Blink source code. To submit a patch you must download the source code by using darcs, see the Source Code section from Download page. Blink is an application not a library/API to be used by other software and the only documentation Blink has, is its code.
How to submit a patch
First make sure you are using the latest version by doing a 'darcs pull'. Then record your changes using 'darcs record'. Follow the following guidelines for recording your changes:
- Keep a patch name under 80 characters, so that a darcs changes in a 80 char console is consistent and readable. If you need to write more than that, use --edit-long-comment or do not specify -m "patch name" and it will automatically ask for a patch name and a long comment. Keep the long comment inside the 80 char frame.
- When you add a long comment, you have the patch name on the first line. After that, leave an empty line and then add the long comment starting from the 1st column. If you need to add bulleted entries in the long comment, use a dash (-) not an asterisk (*), to avoid confusion with the asterisk darcs places before every patch name.
- Record separate patches for each distinct changes you make. Do not mix different changes in a single record.
- Use darcs replace to rename tokens if possible instead of using a search and replace in your editor. It correctly handles cases where someone else still kept using the old name (it will automatically rename this uses of the old name when he pull the darcs replace patch, which a simple token rename done by the editor and recorded as a standard diff will never do, requiring further patches to rename the old tokens that the other developer added in his code while you were doing the renaming).
Finally, send the patch describing your changes at:
darcs send --to devel@ag-projects.com
If you are not sure what and where needs to be modified, ask the question first on the mailing list.