Changes between Version 29 and Version 30 of ru/WorkingGuideLines

Timestamp:

04/25/10 13:56:08 (14 years ago)

Author:

andrew_b

Comment:

--

ru/WorkingGuideLines

@@ -14 +14 @@
 Для облегчения процесса создания тикетов здесь приводятся некоторые рекомендации.
 
-   * Если вы хотите быть ответственным за тикет, то просто установите себя владельцем (owner) тикета и поменяйте статус тикета на 'accepted' (принят). Теперь вы должны наблюдать за тикетом - есть патч или нет патча. В обоих случаях вы должны создать ветку (branch) для последующей работы в ней.
-   * Патчи с исправлениями разрешено применять только к последней стабильной ветке. Эти ветки называются: mc-X.Y (например: mc-4.6). Патчи с новыми возможностями и реструктуризацией (рефакторингом) недопустимы в стабильных ветках - эти патчи нужно применять к основной ветке 'master'. Просьба также выбрать правильное направление (milestone) для данного тикета: для исправления выберите последнее направление от стабильной ветки (напр. 4.6.2). Для остальных патчей или пожеланий выберите направление по умолчанию (в наст. время это 4.7)
-   * Создайте на основе необходимой ветки другую ветку (например, для исправления создайте ветку от ветки mc-4.6). Все создаваемые ветки должны быть созданы на основе самого последнего коммита из родительской ветки. Новые ветки должны следовать правилу наименования: {{{XYZ-<здесь_некоторое_описание>}}}; где XYZ - это номер тикета; описание должно быть осмысленным и коротким, по возможности. Патчи из тикета не применяются непосредственно к родительской ветке, чтобы мы могли их обсудить и при необходимости пересмотреть.
-   * После создания ветки вы должны задать в поле severity значение '''review''' для того, чтобы другие разработчики смогли [http://www.midnight-commander.org/report/9 увидеть] ваш тикет как готовый к обзору и обсуждению. Если данное поле не задано в '''review''' ветка считается нестабильной и подлежит дальнейшей разработке.
+   * Если вы хотите быть ответственным за тикет, то просто установите себя владельцем (owner) тикета. Для этого измените статус тикета на "accepted" (принят). Теперь вы должны наблюдать за тикетом - есть патч или нет патча. В обоих случаях вы должны создать ветку (branch) для последующей работы в ней.
+   * Патчи с исправлениями разрешено применять только к последней стабильной ветке. Эти ветки называются: mc-X.Y (например: mc-4.6). Патчи с новыми возможностями и реструктуризацией (рефакторингом) недопустимы в стабильных ветках - эти патчи нужно применять к основной ветке (master). Просьба также выбрать правильное направление (milestone) для данного тикета: для исправления выберите последнее направление от стабильной ветки (например, 4.6.2). Для остальных патчей или пожеланий выберите направление по умолчанию (в настоящее время это 4.7).
+   * Создайте на основе необходимой ветки другую ветку (например, для исправления создайте ветку от ветки mc-4.6). Все создаваемые ветки должны быть созданы на основе самого последнего коммита из родительской ветки. Новые ветки должны следовать правилу наименования: {{{XYZ_<здесь_некоторое_описание>}}}; где XYZ - это номер тикета; описание должно быть осмысленным и коротким, по возможности. Патчи из тикета не применяются непосредственно к родительской ветке, чтобы мы могли их обсудить и при необходимости пересмотреть.
+   * После создания ветки вы должны задать в поле severity значение '''review''' для того, чтобы другие разработчики смогли [http://www.midnight-commander.org/report/9 увидеть] ваш тикет как готовый к обзору и обсуждению. Если данное поле не задано в '''review''', ветка считается нестабильной и подлежит дальнейшей разработке.
 
 == Руководство по обзору тикетов ==
 
-Так же, как существует руководство по созданию тикетов, существует и руководство по обзору тикетов.
-   * Краткая выдержка [wiki:ru/forReviewer о ревизии кода]
+Так же как существует руководство по созданию тикетов, существует и руководство по обзору тикетов.
+   * Краткая выдержка [wiki:ru/forReviewer о ревизии кода].
    * Список тикетов, которые необходимо просмотреть, находится по адресу: http://www.midnight-commander.org/report/9.
-   * Вы можете просмотреть и протестировать патч, просто переключившись на ветку для этого тикета (но более правильно - провести слияние (merge) ветки с той веткой, для которой он предназначен, и тестировать этот конечный результат):
+   * Вы можете просмотреть и протестировать патч, просто переключившись на ветку, созданную для этого тикета (но более правильно - провести слияние (merge) ветки с той веткой, для которой он предназначен, и тестировать этот конечный результат):
 {{{
  $ # Упрощенный вариант тестирования:
@@ -43 +43 @@
       * код делает то, что должен делать (что было задекларировано в комментарии к патчу)?
       * добавляет ли код новые баги (ошибки)?
-   * Если патч вам нравится (вы не нашли багов и согласны с идеей в патче), то вы должны добавить добавить свой голос в поле голосования за принятие изменения (Votes for changeset) в формате {{{vote-<login>}}}, где логин - это ваш логин в Trac. Если же патч не совсем безгрешный, то вы должны заменить значение поля severity с '''review''' на  '''rework''' и задать ключевым словом характер необходимых изменений:
+   * Если патч вам нравится (вы не нашли багов и согласны с идеей в патче), то вы должны добавить добавить свой голос в поле голосования за принятие изменения (Votes for changeset) в формате {{{<login>}}}, где логин - это ваш логин в Trac. Если же патч не совсем безгрешный, то вы должны заменить значение поля severity с '''review''' на  '''rework''' и задать ключевым словом характер необходимых изменений:
       * если необходимо просто "почистить" патч (убрать лишние пробелы, повставлять отступы и т. д.), то добавьте ключевое слово '''cleanup''';
       * если в в патче присутствуют ошибки (или патч является "хаком"), то необходимо добавить ключевое слово '''rework''';
       * если в патче присутствуют кардинальные изменения, сделающие master несовместимым со стабильной веткой, то такие тикеты должны быть заморожены до момента выпуска релиза на основе ветки master (и перед созданием новой стабильной ветки). Такие тикеты должны быть помечены ключевым стовом '''frozen'''.
-   * В настоящее время необходимы голоса двух разработчиков, чтобы патч был применён к родительской ветке (либо к стабильной ветке, либо к "master"). Если кто-либо вторым добавляет свой голос, то ему необходимо также изменть значение поля severity на '''approved''' (утверждено).
+   * В настоящее время необходимы голоса двух разработчиков, чтобы патч был применён к родительской ветке (либо к стабильной ветке, либо к "master"). Если кто-либо вторым добавляет свой голос, то ему необходимо также изменить значение поля severity на '''approved''' (утверждено).
    * Голосование всегда производится за последний патч в ветке.
    * В ходе обсуждения в тикете либо в ходе просмотра патчей разработчики могут убирать свои голоса при возникновении каких-либо проблем.
@@ -55 +55 @@
 Для публикации ветви можно воспользоваться утилитой [http://git-wt-commit.rubyforge.org/git-publish-branch git-publish-branch]
 
- Примерный сценарий создания бранча можно представить в виде последовательности шагов:
+Примерный сценарий создания бранча можно представить в виде последовательности шагов:
 {{{
   $ git checkout master                // переключение на ветвь "master"
@@ -61 +61 @@
   $ git checkout -b 123_branch_name    // создание локального бранча
 }}}
- Далее необходимо внести изменения в исходные тексты и закоммитить изменения.
+Далее необходимо внести изменения в исходные тексты и закоммитить изменения:
 {{{
-  $ git commit file.1 file.2 file.3    // фиксация изменений
+  $ git add file.1 file.2 file.3       // указание изменённых файлов
+  $ git commit                         // фиксация изменений
   $ git-publish-branch                 // публикация ветви 
 }}}
@@ -69 +70 @@
 == Руководство по применению патчей ==
 
-   * Владелец (ответственный) тикета теперь может внести исправления (находящиеся в ветке {{{XYZ-<здесь_некоторое_описание>}}}) в родительскую ветку.  Если исправления были багфиксингом, то они должны примениться к стабильной ветке (mc-X.Y)
-   * В этом случае (исправление на стабильную ветку) изменения считаются утерянными относительно ветки 'master'. Пожалуйста, '''НИКОГДА(!!!)''' не производите перебазирование (rebase) стабильной ветки относительно "master", чтобы объединить исправления!
+   * Владелец (ответственный) тикета теперь может внести исправления (находящиеся в ветке {{{XYZ_<здесь_некоторое_описание>}}}) в родительскую ветку.  Если исправления были багфиксингом, то они должны примениться к стабильной ветке (mc-X.Y).
+   * В этом случае (исправление на стабильную ветку) изменения считаются утерянными относительно ветки "master". Пожалуйста, '''НИКОГДА(!!!)''' не производите перебазирование (rebase) стабильной ветки относительно "master", чтобы объединить исправления!
    * Обязательно в первом описании коммита указывайте номер тикета в формате #XXX (# - обязательный символ), относительно которого был создан бранч, примерно так:
 {{{
@@ -80 +81 @@
    * После первой строки описания коммита добавьте дополнительный перенос строки.
 
-   В тривиальном случае перед вливанием в master можно произвести объединение нескольких коммитов. Примерно так:
+В тривиальном случае перед вливанием в master можно произвести объединение нескольких коммитов. Примерно так:
 {{{
  $ git rebase -i HEAD~4  //если коммитов было 4
@@ -89 +90 @@
 }}}
 
-  Пример слияния с master:
+Пример слияния с master:
 {{{
  $ git checkout master              // переключение на ветвь "master"
@@ -99 +100 @@
 }}}
 
-  Далее:
+Далее:
 {{{
  $ git merge --log --no-ff 123_branch_name  // слияние с "master" той ветви, которую необходимо слить
@@ -107 +108 @@
   * ключ --no-ff позволяет сгенерировать коммит слияния даже в том случае, если ветвь является дочерней от вершины родителя (по нему проще отследить, какие патчи были сделаны в рамках данного тикета). Этот ключ значительно упрощает понимание взаимосвязей коммитов.
 
-  Далее:
+Далее:
 {{{
  $ git push origin master           // обновление данных в удаленном репозитарии
@@ -115 +116 @@
 
    * Если слияние произошло с ошибкой (из-за конфликтов), то необходимо вручную исправить конфликты и продолжить слияние. В идеале такого было не должно. Все тикеты _крайне_ желательно проверять, предварительно смержив тестируемую ветку с той, в которую планируется её добавить; иначе в ветку попадает другой код (который в некоторых случаях не только не работает, но даже и не собирается).
-   * Теперь вы можете просто закрыть тикет с причиной закрытия "Fixed" (исправлено), необходимо изменить severity на '''merged''', в поле Votes нужно указать ветвь, с которой происходило слияние (например, "commited-master"/"master"). Состояние тикета автоматически меняется на "testing".
-   * После этого перейдите на страницу http://midnight-commander.org/timeline, скопируйте оттуда ссылку на результат слияния и добавьте ее в последнем комментарии примерно так:
+   * Теперь вы можете просто закрыть тикет с причиной закрытия "Fixed" (исправлено), необходимо изменить severity на '''merged''', в поле Votes нужно указать ветвь, с которой происходило слияние (например, "committed-master"/"commited-stable"). Состояние тикета автоматически изменяется на "testing".
+   * После этого перейдите на страницу http://midnight-commander.org/timeline (или воспользуйтесь командой {{{git log}}}), скопируйте оттуда ссылку на результат слияния и добавьте её в последнем комментарии примерно так:
 {{{
 #!comment 
@@ -132 +133 @@
 Если Вы не знакомы с git, пожалуйста, ознакомьтесь с нашим небольшим [wiki:ru/GitGuideLines руководством по git].
 
-С описанием процесса выпуска релизов продукта можно ознакомиться [wiki:ru/ReleaseProcess здесь]
+С описанием процесса выпуска релизов продукта можно ознакомиться [wiki:ru/ReleaseProcess здесь].