15 | | To ease this here are some Guidelines for creating of tickets: |
16 | | * 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. |
17 | | * 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). |
18 | | * 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. |
19 | | * Please note that *each* patch should contain also a patchset for the Changelog so that this file always reflect what changes have been done in a branch. |
20 | | * After creating the branch, you should not forget to add this keyword: "review" to your ticket, since now your ticket will pop up on [http://www.midnight-commander.org/report/9 this page] and can be reviewed by other developers. |
| 15 | Here are some useful tips for creating tickets: |
| 16 | * 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. |
| 17 | * 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). |
| 18 | * Please note that Changelog is frozen and mustn't be modified. All the modifications should be drawn in the commit message. |
| 19 | * 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 [http://www.midnight-commander.org/report/9 this page] and can be reviewed by other developers. |
| 20 | |
| 21 | == Creating branches == |
| 22 | * 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. |
| 23 | * 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) |
28 | | * looks the code well? (see CodingGuideLines) |
29 | | * does the code what it should does? |
30 | | * introduces this code new bugs? |
31 | | * 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". |
32 | | * 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 "approved" keyword to the keywords list. |
| 31 | * is the patch looking well? (see CodingGuideLines) |
| 32 | * is the patch doing what it should? |
| 33 | * the patch mustn't introduce new bugs! |
| 34 | * 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. |
| 35 | * 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". |