2. Ресурсы для разработки

2.1. Исходные коды пакета Planner

Исходный код хранится в репозитории git в базе данных Gnome Git. Код можно клонировать при помощи следующей команды:

git clone git://git.gnome.org/planner

Вы также можете скачать архивы более ранних выпусков пакета Planner в формате tarball.

2.2. Планы дальнейших работ над Planner

Ниже приведены ближайшие планы в порядке важности:

  1. уменьшить расхождение с нисходящим по течению, интегрируя патчи
  2. рассмотреть и интегрировать патчи из bugzilla
  3. обеспечить лучшую поддержку для Windows и OSX
  4. мигрировать на современные технологии

2.3. Использование GNOME Bugzilla в Planner

Разработка в Planner отслеживается при помощи системы отслеживания ошибок GNOME. При обнаружении любой проблемы или требований новой функциональности сперва ищите информацию в системе отслеживания ошибок. Вы можете работать над исправлением любых проблем, замеченных в Planner. Если вы новичок, вы можете найти некоторые проблемы, которые нетрудно решить, в данном списке.

2.4. Инструкции по построению из исходного кода

В Приложении 1 приведено описание «Сборка и установка пакета Planner под Unix/Linux», которое может быть полезно и при построении Planner в других UNIX-подобных системах. Также доступно описание «Сборка и установка пакета Planner под Windows», приведенное в Приложении 2.

2.5. Как принять участие

Мы ищем больше людей, готовых присоединиться к команде разработки (так много дел, и так мало времени ;-)). Первое, что нужно сделать, если вы хотите принять участие – подписаться на списки рассылки, также предпочтительно присоединиться к каналу IRC. Не стесняйтесь задавать любые вопросы, которые могут возникнуть при просмотре кода.

2.6. Подготовка и отправка патчей

Вот несколько советов по созданию и отправке хороших патчей:

  • Всегда создавайте патч относительно самого свежего git master
  • Если вы вносите изменения в расположение символов пробела, держите их в отдельном патче. Это будет сохранить патч функциональности маленьким и читаемым, а патч с пробелами можно будет легко проверить, чтобы убедиться, что он не содержит ничего, кроме изменений в символах пробела (diff -w).
  • Убедитесь, что ваши изменения не генерируют предупреждения компилятора (warnings). Исправьте проблему, о которой предупреждает компилятор, а не просто подавляйте предупреждение.
  • Прежде чем отправлять патч, проверьте его, чтобы убедиться, что он содержит только те изменения, которые вы планируете включить (без изменений в расположении пробельных символов, без оставленного отладочного кода, без новых функций, которые вы собирались использовать, но не использовали, …)
  • Если размер патча превышает 40K, пожалуйста, поместите его куда-либо, откуда люди смогут загрузить его и отправьте ссылку на патч вместо патча
  • либо отправьте его в список рассылки planner-dev, либо (предпочтительно) создайте отчет об ошибке и прикрепите патч к отчету (вы сможете прикрепить файлы к отчету об ошибке только после размещения этого отчета в системе)
  • Используйте git format-patch, чтобы генерировать патч. Подготавливайте исправления для каждого логического шага или постоянного набора модификаций и не бойтесь использовать git rebase -i, прежде чем отправлять патчи. Постарайтесь сохранить баланс между слишком большими патчами и слишком большим количеством патчей.

2.7. Иные способы помощи

Если вы предпочитаете не начинать программировать сразу, есть и другие способы помочь. Один из них – найти ошибки, которые были решены, но не были помечены как FIXED в Bugzilla. Чтобы идентифицировать их, вы должны сначала найти надежный способ воспроизведения их со старой версией (имеется в виду версия, использованная автором сообщения), а затем пройти через те же шаги со свежей версией из репозитория git, чтобы показать, что проблема решена и ошибка не воспроизводится.

2.7.1. Получение копии исходного кода

cd ~
git clone git://git.gnome.org/planner
cd planner

Это нужно только сделать один раз. Затем для каждого отчета об ошибке, с которым вы работаете, можно повторять следующие шаги.

2.7.2. Воспроизведение проблемы

Попробуйте воспроизвести проблему с той же версией, что и автор отчета об ошибке:

Узнайте имя тега для старой версии, которая вам нужна, по адресу http://git.gnome.org/cgit/planner/refs/tags.

git checkout TAG
./autogen.sh --prefix=${HOME}/local
make install   # will install to the 'local' directory in your home directory
export PATH=${PATH}:${HOME}/local/bin
planner

2.7.3. Проверка, была ли проблема решена

Как только вы выяснили, как надежно воспроизвести проблему, попробуйте сделать то же самое в новейшей версии Planner:

git checkout master
./autogen.sh --prefix=${HOME}/local
make install   # will overwrite the currently installed version in the 'local' directory in your ${HOME}
planner

Если вы видите, что в новейшей версии проблема не возникает, даже если вы совершали именно те шаги, при которых проблема в старой версии возникала в 100% случаев, вы должны добавить запись к отчету об ошибке, сообщая, что проблему можно пометить как FIXED. Также опишите шаги, которые вы совершали, чтобы надежно воспроизвести проблему, если они четко не упоминаются в отчете об ошибке. На самом деле добавление описания шагов в отчет об ошибке, в котором не хватает этой информации, всегда полезно, независимо от того, остается ли ошибка в самой свежей версии.

2.7.4. Получение новейших обновлений исходного кода

Время от времени, когда разработчики вносят новые изменения в центральный репозиторий, вы можете при помощи команды git pull в вашей локальной директории проекта получить эти изменения.