MakePatches — различия между версиями
м (1 версия) |
|||
| (не показаны 3 промежуточные версии 2 участников) | |||
| Строка 1: | Строка 1: | ||
| − | + | === Создание патчей к WINE === | |
| − | + | ||
| + | С учётом опыта поддержки созданных патчей, | ||
| + | предлагаю следующие правила: | ||
| − | + | 1.Существенное изменение кода стараемся выносить в функцию, чтобы минимально влезать в вайновский код (вызывая в нём только функцию). | |
| + | 2.При необходимости удаления строк с кодом помещайте их в комментарии, или в | ||
| + | <pre><nowiki>#if 0 ... #endif.</nowiki></pre> | ||
| + | Не забывайте комментарий — что и почему удалено. | ||
| + | 3.К каждому изменению, не отправляемому в winehq (то есть хаку, который не будет принят), должен быть написан комментарий и ссылка на багу, например: | ||
| + | <pre>/* Eterhack: Fix window focus for Garant (eterbug #1234) */</pre> | ||
| + | 4.В названии коммита для eterhack также нужно указывать ссылку на багу вида (eterbug #1234), например: | ||
| + | |||
| + | <pre>gdi32: Fix window focus for Garant (eterbug #1234).</pre> | ||
| + | |||
| + | 5.Нельзя создавать коммит с одним только '''fix bug 1234''' в названии, без описания изменения. | ||
| + | |||
| + | 6.Очень не желательно в конце строки оставлять пробел, или добавлять новые строки, состоящие из кучи пробелов. | ||
| + | |||
| + | Пример из недавно присланного патча: | ||
| + | |||
| + | <pre> | ||
| + | + LOADETER_FUNC(etersoft_getlicense); | ||
| + | + LOADETER_FUNC(etersoft_getversion); | ||
| + | + |<- Вот где реально стоит переход на новую строку | ||
| + | + /* | ||
| + | + * Out text informatioun | ||
| + | </pre> | ||
| + | |||
| + | В Kwrite и KScope такие пробелы должны быть хорошо видны. | ||
| + | |||
| + | 7.Название коммитов. Общепринятый формат: имя библиотеки/программы в начале названия. потом двоеточие, и с заглавной буквы описание изменения. | ||
| + | Например: | ||
| + | |||
| + | <pre>gdi32: Correct display of ticks (eterbug #6750).</pre> | ||
| + | |||
| + | Так проще потом просматривать репозитории, воспринимать патчи. Да и стилю winehq соответствует, стоит привыкнуть, чтобы отправлять патчи с "правильным" | ||
| + | для них названием. | ||
| + | |||
| + | 8.Не допускайте смешивания в одном коммите изменения форматирования кода и изменения самого кода. Если нужно переформатировать код (внести изменения, не меняющие смысла), сделайте это отдельным коммитом. | ||
| + | |||
| + | Просмотреть результат отправленного в winehq патча можно здесь: | ||
| + | |||
| + | *[http://source.winehq.org/patches/ http://source.winehq.org/patches/] | ||
| + | *[http://testbot.winehq.org/ http://testbot.winehq.org/] | ||
| + | |||
| + | При принятии в winehq патчей, созданных в Etersoft (отправленных в winehq с почты @etersoft.ru), в нашу рассылку приходит автоматическое извещение. | ||
| + | |||
| + | ==Правила хорошего тона в Winehq== | ||
| + | |||
| + | После создания патча для локальной версии wine его можно, если он удовлетворяет требованиям патчей winehq отправить им по электронной почте: <br/ > | ||
| + | '''wine-patches@winehq.org''' | ||
| + | |||
| + | Несколько ссылок на то как делают патчи и какой стиль предпочтительнее в winehq: | ||
| + | * http://www.winehq.org/docs/winedev-guide/codingpractice#PATCH-FORMAT | ||
| + | * http://www.winehq.org/docs/winedev-guide/style-notes | ||
| + | |||
| + | Посмотреть список приложенных патчей, которые должен проверить TestRobot и их статус winehq можно по: | ||
| + | * http://source.winehq.org/patches/ | ||
| + | * http://testbot.winehq.org/ | ||
=== Ссылки === | === Ссылки === | ||
| + | *[http://wiki.winehq.org/SubmittingPatches Об отправке патчей на англ.] | ||
| − | [ | + | [[Категория:Разработка]] |
| + | {{Wine}} | ||
Текущая версия на 15:57, 8 января 2015
Создание патчей к WINE
С учётом опыта поддержки созданных патчей, предлагаю следующие правила:
1.Существенное изменение кода стараемся выносить в функцию, чтобы минимально влезать в вайновский код (вызывая в нём только функцию).
2.При необходимости удаления строк с кодом помещайте их в комментарии, или в
#if 0 ... #endif.
Не забывайте комментарий — что и почему удалено.
3.К каждому изменению, не отправляемому в winehq (то есть хаку, который не будет принят), должен быть написан комментарий и ссылка на багу, например:
/* Eterhack: Fix window focus for Garant (eterbug #1234) */
4.В названии коммита для eterhack также нужно указывать ссылку на багу вида (eterbug #1234), например:
gdi32: Fix window focus for Garant (eterbug #1234).
5.Нельзя создавать коммит с одним только fix bug 1234 в названии, без описания изменения.
6.Очень не желательно в конце строки оставлять пробел, или добавлять новые строки, состоящие из кучи пробелов.
Пример из недавно присланного патча:
+ LOADETER_FUNC(etersoft_getlicense); + LOADETER_FUNC(etersoft_getversion); + |<- Вот где реально стоит переход на новую строку + /* + * Out text informatioun
В Kwrite и KScope такие пробелы должны быть хорошо видны.
7.Название коммитов. Общепринятый формат: имя библиотеки/программы в начале названия. потом двоеточие, и с заглавной буквы описание изменения. Например:
gdi32: Correct display of ticks (eterbug #6750).
Так проще потом просматривать репозитории, воспринимать патчи. Да и стилю winehq соответствует, стоит привыкнуть, чтобы отправлять патчи с "правильным" для них названием.
8.Не допускайте смешивания в одном коммите изменения форматирования кода и изменения самого кода. Если нужно переформатировать код (внести изменения, не меняющие смысла), сделайте это отдельным коммитом.
Просмотреть результат отправленного в winehq патча можно здесь:
При принятии в winehq патчей, созданных в Etersoft (отправленных в winehq с почты @etersoft.ru), в нашу рассылку приходит автоматическое извещение.
Правила хорошего тона в Winehq
После создания патча для локальной версии wine его можно, если он удовлетворяет требованиям патчей winehq отправить им по электронной почте:
wine-patches@winehq.org
Несколько ссылок на то как делают патчи и какой стиль предпочтительнее в winehq:
- http://www.winehq.org/docs/winedev-guide/codingpractice#PATCH-FORMAT
- http://www.winehq.org/docs/winedev-guide/style-notes
Посмотреть список приложенных патчей, которые должен проверить TestRobot и их статус winehq можно по:
