On Tue, 08 Nov 2011, tourettes deprecated this page or content. Please see Patch Policy (GIT)

If you are a developer and want to contribute to MediaPortal, then you might wonder what you could do.

Your first stop should be our Mantis. Or the roadmaps to be more specific.

• MediaPortal 1
• TV-Server
• DeployTool / NSIS

There you can find all the confirmed bugs and new features or reworks the Team has already agreed to add. If an issue is not yet assigned to an developer, then you can give it a try if you want. Remember that following these guidelines and providing multiple good patches could be your road to the ultimate success (read becoming a member of Team MediaPortal).

Guidelines

• If you decide to work on an unassigned issue in our Roadmap, then it would be wise to create a work in progress (WIP) thread inside the submit patch forums to avoid that others work on the very same issue. You can also use this thread to team up with other developers or discuss the changes with the team.
• Patch should be always created from the HEAD SVN tree. This will make it much easier to merge the patch as there is no need to find the correct folder from where the patch was created.
• At best always use the latest SVN revision as basis of your work
• Only one feature bug fix is allowed to be submitted.
• Test the patch throughout. If the patch causes some regression (or has bugs in the new functionality) it will just be ignored or reverted from SVN. Patch author is responsible for fixing the patch, no the team members.
• When changing or adding functionality you are obligated to provide documentation update for the wiki. It is enough to write all the needed documentation changes inside [quote][/quote] tags in the same forum thread where the patch itself is provided. For example adding a new feature into the skinning engine or changing the existing behavior of skinning engine always requires a wiki update.
• Make sure that the patch is following the Coding Standards.
• Make sure that the patch is using correct indentation, tabs converted as two spaces (this can be changed from Visual Studio's settings).
• Code beautification shouldn't be done as an extra to some patch. Code beautification or coding convention related changes should be done as a separate patch.
• Remember to write good code comments. i.e. comment all code that needs some explanation. Commenting trivial code is not needed. Remember that code comments should be always be meaningful - not something like "incrementing lap counter".
• Use a meaningful forum topic for your patch submission. It is pretty easy fer developers to skip patch submission threads that have topics like "Fix for error in TVE3 / MediaPortal".  The thread title should already point out what the patch is about.
• When making a update to a patch always send a complete patch. It is very time consuming and error prone for other people to combine a patch from multiple sources.
• Failing to follow any of these guidelines is good enough reason to get your patch rejected.

Create the unified diff ( .patch )

In order to make a devs life easier we would like to receive patches only in the unified diff format ( .patch ).

How to create a patch with TortoiseSVN:

1. Once you have your code changes working, please enter each directory where you added a file, right click it and use the menu TortoiseSVN -> Add.
   
2. Then right click the top most directory and select TortoiseSVN -> Create patch:
   
3. Check carefully, that all new and modified files are in the upcoming screen:
   
4. Finally confirm with ok and specify a INTUITIVE file name like:
   

Submit the Patch

This is the easiest step of the entire procedure.

You just have to go to the submit patch forum and start a new thread.

When starting the thread, please:

1. Include a detailed explaination what this change is about
2. Provide information about the SVN revision your patch is based on
3. Attach the .patch file

Our developers will then review your patch and change the status of your thread accordingly.

Work Flow

Your submitted patch will be tagged by team members to indicate the current step in the workflow.

• Pending
• Evaluating
• Approved or rejected

In some cases you may be asked to revise your patch, in this case the thread status should be changed to WIP (Work in Progress).