MakePatches — различия между версиями
м (переименовал «WINE/MakePatches» в «MakePatches») |
|||
| Строка 1: | Строка 1: | ||
| − | + | === Создание патчей к 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. Очень не желательно в конце строки оставлять пробел, или добавлять новые строки, состоящие из кучи пробелов. | ||
| + | Пример из недавно присланного патча: | ||
| + | |||
| + | <pre>+ LOADETER_FUNC(etersoft_getlicense); | ||
| + | + LOADETER_FUNC(etersoft_getversion); | ||
| + | + |<- Вот где реально стоит переход на новую строку | ||
| + | + /* | ||
| + | + * Out text informatioun</pre> | ||
| + | |||
| + | В Kwrite и KScope такие пробелы должны быть хорошо видны. | ||
| + | |||
| + | 7. Название коммитов. Общепринятый формат: имя библиотеки/программы в начале названия. потом двоеточие, и с заглавной буквы описание изменения. | ||
| + | Например: | ||
| + | gdi32: Correct display of ticks (eterbug #6750). | ||
| + | |||
| + | Так проще потом просматривать репозитории, воспринимать патчи. Да и стилю 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/ | ||
| Строка 14: | Строка 64: | ||
[http://wiki.winehq.org/SubmittingPatches Об отправке патчей на англ.] | [http://wiki.winehq.org/SubmittingPatches Об отправке патчей на англ.] | ||
| + | |||
| + | [[Категория:Разработка]] | ||
Версия 16:17, 28 ноября 2012
Создание патчей к 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 патча можно здесь:
http://source.winehq.org/patches/
При принятии в 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 можно по:
