Changes between Version 10 and Version 11 of WorkingGuideLines


Ignore:
Timestamp:
08/20/09 08:46:28 (15 years ago)
Author:
iNode
Comment:

update translation from ru

Legend:

Unmodified
Added
Removed
Modified

  • WorkingGuideLines

    v10 v11  
    1010 * applying patch 
    1111 
     12 
    1213== Creating Ticket Guidelines == 
    1314Here are some useful tips for creating tickets: 
    … …  
    1516 * 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).  
    1617 * Please note that Changelog is frozen and mustn't be modified. All the modifications should be drawn in the commit message. 
    17  * 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. 
     18  
    1819 
    1920== Creating branches == 
     21 
     22To publish branch you can use script git-publish-branch 
     23 
     24Simple example to create branch: 
     25{{{ 
     26  $ git checkout master 
     27  $ git pull                           // pull last changes 
     28  $ git checkout -b 123_branch_name    // create local branch 
     29}}} 
     30 
     31Add changes and commit: 
     32{{{ 
     33  $ git commit file.1 file.2 file.3    // commit changes 
     34  $ git-publish-branch                 // pub branch 
     35}}} 
     36 
    2037 * 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. 
    21  * 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) 
     38 * 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). Please create your branches upon a last master/another_parent_branch, it will simplfy future merge process.  
     39 
     40 * After creating the branch, you shouldn't forget to set "Severity" field to the "on review" state if it ready for review, since now your ticket will pop up on [http://www.midnight-commander.org/report/9 this page] and can be reviewed by other developers. Also don't forget add link to changeset in ticket it should speed up review process.  
     41  
     42Standard format is: 
     43{{{ 
     44branch: branch_name (parent: parent_branch_name) 
     45changeset:changeset_hash 
     46}}} 
     47 
    2248 
    2349== Reviewing Ticket Guidelines == 
    2450As there are some guidelines for creating tickets, there are of course also some guidelines for reviewing tickets. 
    2551 * Tickets which needs a review are located here: http://www.midnight-commander.org/report/9 
    26  * You can directly test the patch in git, simply checkout this branch and test and review it.  
     52 * You can directly test the patch in git, simply checkout this branch and test and review it (or test merge with 
     53 current local master branch or another branch which should be merged for check to conflicts). 
     54 
     55{{{ 
     56 $ # simple test case: 
     57 $ git checkout origin/123_branch_name 
     58 $ <build and test> 
     59}}} 
     60{{{ 
     61 $ # best test case: 
     62 $ git checkout master 
     63 $ git reset --hard origin/master 
     64 $ git pull 
     65 $ git merge --log --no-ff origin/123_branch_name 
     66 $ <build and test> 
     67}}} 
     68 
    2769 * This should be reviewed when looking at a patch: 
    2870   * is the patch straightforward or a somehow hackish fix for an issue? 
    … …  
    3072   * is the patch doing what it should? 
    3173   * the patch mustn't introduce new bugs! 
    32  * 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. 
     74 * 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 and describe whats problems with this patch. 
    3375 * 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". 
    3476 
    … …  
    3678The last part is about applying a accepted patch to it's parent one 
    3779 * 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.  
    38  * 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.  
    39  * 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: 
     80 * 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.  
     81 * Don't forget add correct commit message. Standard format is: 
     82 {{{ 
     83    Ticket #<ticket_number>: ticket summary 
     84 
     85    changeset description, e.g. 
     86    add: some description 
     87    fix: some description 
     88 }}} 
     89 Some examples to merge your changes. 
     90 Rebase to merge commits in one: 
    4091{{{ 
    41 git-diff 111111111111111^...222222222222222 
     92 # in you working branch 
     93 $ git rebase -i HEAD~4  // if you add 4 commit (you can check it with 'git log') 
     94}}} 
     95  Preparing to merge with master: 
     96{{{ 
     97 $ git checkout master 
     98 $ git pull                         // don't forget update your master 
     99 $ git checkout 123_branch_name     // checkout your working branch 
     100 $ git rebase origin/master         // rebase you working branch to "master" 
     101 $ git checkout master              // againt to master 
     102 $ git pull                         // and check updates 
     103}}} 
     104  Merge process, if you has just one commit: 
     105{{{ 
     106 $ git merge --log 123_branch_name  // слияние с "master" той ветви, которую необходимо слить 
     107}}} 
     108 
     109 If you have more than one commit: 
     110{{{ 
     111 $ git merge --log --no-ff 123_branch_name  // слияние с "master" той ветви, которую необходимо слить 
     112}}} 
     113   option --log add to commit list of merged patches, option --no-ff allow create merge commit in case where branch isn't child branch for current head, it should simplify understanding commit relation.  
     114 
     115 Now you ready to update master branch on server:  
     116{{{ 
     117 $ git push origin master           // update central repository 
     118 $ git push origin :123_branch_name // delete bracnh 123_branch_name on server 
     119 $ git branch -d 123_branch_name    // delete local branch 123_branch_name on your host 
     120}}} 
     121 
     122 If you has any problems in merge process you should fix it manually and continue merge process, but try to check merge process before start to push or you can break branch. 
     123 
     124   * После этого перейдите на страницу http://midnight-commander.org/timeline, скопируйте оттуда ссылку на результат слияния и добавьте ее в последнем комментарии примерно так: 
     125 * Now you can close the ticket and the ticket will change into the testing state, and add to keywords name of branch you merge with (e.g. mater/commited-master). In ticket you must describe how get summary patch. For example: 
     126{{{ 
     127fixed: 111111111111111^...222222222222222 # for multipatch 
     128fixed: 111111111111111                    # for one changeset 
    42129}}} 
    43130 where 111111111111111 - first commit; 222222222222222 - last commit 
    … …  
    45132 
    46133If you are unfamiliar with git, please have a look before working in our GitGuideLines.  
     134 
     135Release process should be described [wiki:ReleaseProcess here]. 
     136