WorkingGuideLines

This document represents Guidelines for our Workflow.

Workflow

It is divided into several parts:

• creating ticket
• creating branches
• reviewing patch
• applying patch

Creating Ticket Guidelines

Here are some useful tips for creating tickets:

• If you want to be responsible for a ticket, simply set yourself as owner and status to accepted. Don't forget to have a look if this ticket already contains a patch. Now create a remote branch for working in.
• Bugfixes are allowed to go to the latest stable branch and new features and restructuring are allowed only for full releases. Stable branches are called: mc-X.Y (e.g. mc-4.6). 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), and for a new feature choose the default (which is atm 4.7).
• Please note that Changelog is frozen and mustn't be modified. All the modifications should be drawn in the commit message.
• After creating the branch, you shouldn't forget to set "Severity" field to the "on review" state, since now your ticket will pop up on ​this page and can be reviewed by other developers.

Creating branches

• Each 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.
• Each branch is created on the top of the other one. If this is a bugfix you should use stable branch, if not then master branch or branch where this bug (e.g for a bugfix create a branch on top of mc-4.6)

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: ​http://www.midnight-commander.org/report/9
• 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?
  • is the patch looking well? (see CodingGuideLines?)
  • is the patch doing what it should?
  • the patch mustn't introduce new bugs!
• If you're fine with this patch add your login to the "Votes for changeset" field, else if the patch is not okay, then remove votes and set the "Severity" field to "on rework" as keyword.
• Currently two votes are needed in order to get a patch into the parent branch. If you are the second one which have successfully reviewed this patch then you also set the "Severity" field to "approved".

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. In ticket you must describe how get summary patch. For example:

  git-diff 111111111111111^...222222222222222
  

  where 111111111111111 - first commit; 222222222222222 - last commit
• 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.