Changes between Version 8 and Version 9 of WorkingGuideLines


Ignore:
Timestamp:
07/31/09 12:27:15 (15 years ago)
Author:
styx
Comment:

some rework

Legend:

Unmodified
Added
Removed
Modified
  • WorkingGuideLines

    v8 v9  
    33Translates to other languages: [http://www.midnight-commander.org/wiki/RuWorkingGuideLines Русский],  
    44 
    5 As there are many people to coordinate we need some written down Guidelines for our Workflow. 
    6  
     5This document represents Guidelines for our Workflow. 
    76 
    87== Workflow == 
    9 Our workflow is divided into several parts: 
    10  * creating ticket (with patch attached) 
     8It is divided into several parts: 
     9 * creating ticket 
     10 * creating branches 
    1111 * reviewing patch 
    1212 * applying patch 
    1313 
    1414== Creating Ticket Guidelines == 
    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. 
     15Here 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) 
    2124 
    2225== Reviewing Ticket Guidelines == 
     
    2629 * This should be reviewed when looking at a patch: 
    2730   * is the patch straightforward or a somehow hackish fix for an issue? 
    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". 
    3336 
    3437== Applying Patch Guidelines ==