WorkingGuideLines

As there are many people to coordinate we need some written down Guidelines for our Workflow.

Workflow

Our workflow is divided into several parts:

• creating ticket (with patch attached)
• reviewing patch
• applying patch

Creating Ticket Guidelines

To ease this here are some Guidelines for creating of tickets:

• If you want to be responsible for a ticket, simply set you as owner and status to accepted. Now you have to have a look if this ticket already contains a patch or a patch is missing. In both cases create a remote branch for working in.
• Bugfixes are allowed to go the the latest stable branch. These branches are called: mc-X.Y (e.g. mc-4.6), new features and restructurement are not allowed to go into a stable branch, but should go into the next full release. This patch then should go into the master branch. Please also choose the correct milestone for this ticket: For a bugfix choose the latest milestone from the stable branch (e.g. 4.6.2) for a new feature choose the default (which is atm 4.7).
• Create on top of the appropiate branch another branch (e.g for a bugfix create a branch on top of mc-4.6) This branch should follow some easy naming rules: XYZ_<something_descriptive_here>. XYZ is here the ID of the ticket. The patch is not directly applied to the parent branch as we would like to review it beforehand.
• After creating the branch, you should not forget to add this keyword: "review" to your ticket, since now your ticket will pop up on $MISSING_LINK and can be reviewed by other developers.

Reviewing Ticket Guidelines

As there are some guidelines for creating tickets, there are of course also some guidelines for reviewing tickets.

• Tickets which needs a review are located here: $MISSING_LINK
• You can directly test the patch in git, simply checkout this branch and test and review it.
• This should be reviewed when looking at a patch:
  • is the patch straightforward or a somehow hackish fix for an issue?
  • looks the code well? (see CodingGuideLines?)
  • does the code what it should does?
  • introduces this code new bugs?
• If you're fine with this patch add a keyword: "vote-<yourloginname>", but please let review in place. In case the patch is not okay, you can choose if it simply needs some cleanup (e.g. mixing Space vs Tabs for intending, ...), then remove the review keyword and add "cleanup" as keyword, or if the patch is broken or hackish.. then replace "review" with "rework".
• Currently two "vote-<yourloginname>" are needed in order to get a patch into the parent branch (either mc-4.6 or master). If you are the second one which have successfully reviewed this patch then also add a "accepted" keyword to the keywords list.

Applying Patch Guidelines

The last part is about applying a accepted patch to it's parent one

• The owner of the ticket will now merge the fix (located in the XXY_<something_descriptive_here> branch) into the parent branch. For this he eventually has to rebase this branch on the parent one. If the fix was a bugfix, then the fix would be now in the mc-X.Y branch.
• In this case the fix is still missing in the master branch. Please never!!!! rebase the stable release branch mc-X.Y in order to get a fix merged. If the merge failed because of conflicts fix them manually.
• Now you can simply close the ticket and the ticket will change into the testing state.
• After some time of testing a ticketadmin will close it finally.

If you are unfamiliar with git, please have a look before working in our GitGuideLines.