Отправить исправления ошибок на панели запуска с помощью исправлений или предложений по слиянию?

Question

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

Когда я регистрирую ошибки, а затем выясняю, как их исправить, я помещаю исправление в нашу стабильную ветку. Как мне опубликовать исправление обратно в основной проект? Я мог бы создать файл патча и прикрепить его к ошибке, или я мог бы предложить объединить нашу стабильную ветку.

Если я исправлю несколько ошибок, могу ли я сделать отдельное предложение по слиянию для каждой из них, или они накапливаются?

Answer 1

Обновление: похоже, в официальной документации проекта OpenERP теперь есть рекомендации по внесению предложений по слиянию. Я также оставлю свою версию здесь, потому что она имеет некоторые другие детали.

После нескольких дней игры с Bazaar и Launchpad и отправки нескольких исправлений и предложений по слиянию я решил написать краткое изложение того, что нашел. Launchpad и Bazaar предоставляют некоторые мощные инструменты, особенно для проектов, управляемых сообществом, но я не думаю, что новые пользователи, скорее всего, попадут в пропасть успеха. Есть несколько способов сделать процесс медленным и разочаровывающим, поэтому я надеюсь, что этот шаг поможет некоторым людям избежать нескольких ошибок.

Вот рабочий процесс, который я изучил, работая над исправлением ошибок и отправкой предложений по слиянию в команду для проекта, размещенного на Launchpad. Я работаю на рабочей станции GNU/Linux, но я предполагаю, что команды Bazaar будут эквивалентны на других платформах. В этом примере я работаю над одним из проектов в группе проектов OpenObject под названием OpenObject Addons. Имя пользователя сопровождающего - openerp. Я положу свое рабочее место в ~/workspace папка.

Если вы хотите узнать больше о любой из команд здесь, используйте bzr help плюс имя команды.

Создать общий репозиторий

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

Проверьте формат репозитория на официальной ветке:

bzr info http://bazaar.launchpad.net/~openerp/openobject-addons/5.0

Получить код

Теперь создайте рабочую папку, в которой будут храниться все локальные ветви на вашем компьютере - я просто назову ее в честь проекта. Затем создайте в нем общий репозиторий в формате, который вы нашли в официальной ветке.

cd ~
mkdir workspace
cd workspace
mkdir openobject-addons
cd openobject-addons
bzr init-repo --format=rich-root-pack .

Следующим шагом является проверка исходного кода из официальной ветки. Обычно это называется trunk, но вы можете предпочесть работать со стабильной веткой релиза, которая просто используется для исправления ошибок. В этом примере я собираюсь работать над веткой релиза 5.0.

cd ~/workspace/openobject-addons
bzr checkout lp:~openerp/openobject-addons/5.0/ feature-x

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

Создать ветку

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

После того, как вы настроили свою учетную запись, вы можете опубликовать свою ветку как копию официальной ветки и начать работать с ней. lp-login команда сообщает bazaar, какое имя учетной записи использовать на сайте панели запуска, и whoami Команда сообщает bazaar, какое имя использовать в каждой ревизии, которую вы фиксируете. Адрес электронной почты, который вы используете в whoami должен совпадать с одним из адресов электронной почты, настроенных для вашей учетной записи Launchpad.

cd ~/workspace/openobject-addons/feature-x
bzr lp-login donkirkby
bzr whoami "Don Kirkby <[e-mail]>"
bzr branch --stacked --switch lp:~openerp/openobject-addons/5.0/ lp:~donkirkby/openobject-addons/feature-x

Вы переключаетесь на новую ветку, чтобы фиксации были записаны в вашей локальной истории и в вашей публичной ветке. Возможно, вы захотите узнать о разнице между оформлением заказа и филиалом. Создание этой ветки с накоплением означает, что ее создавать очень быстро, потому что она содержит только историю, которой нет в официальной ветке. Это сообщение в блоге звучит так, как будто ветки публичных проектов должны по умолчанию работать в стеке, но это не сработало для меня. Обратите внимание, что я назвал ветку в честь какой-то функции, которую я хочу добавить. Как предложил bialix, я создаю отдельную ветку для каждой функции, которую я в конечном итоге предложу объединить с официальной веткой.

Совершить и сделать предложение о слиянии

Теперь, когда у вас есть ветка, вы можете вносить изменения в код и фиксировать их.

cd ~/workspace/openobject-addons/feature-x
bzr commit -m "Fixed bug lp:12345 by fleaking the woverbinate() function."

Вы можете зафиксировать в любом месте внутри структуры ветки, и она фиксирует всю ветку по умолчанию. Бежать bzr help commit для деталей. Вы также можете найти bzr status а также bzr diff полезно.

Как только вы будете довольны изменениями и добавите все в свою ветку функций, вы можете перейти на веб-сайт Launchpad и создать предложение о слиянии. Вот удобный ярлык, который вы можете запустить для запуска веб-страницы филиала:

cd ~/workspace/openobject-addons/feature-x
bzr lp-open

Как только вы создадите предложение о слиянии, Launchpad сгенерирует для него diff. Стоит рассмотреть этот дифференциал. Иногда я выбирал не ту ветвь в качестве цели, и я заметил это только потому, что в diff было больше изменений, чем я ожидал. Там также есть bzr send Команда для предложения слияния, но я не использовал его.

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

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

Текущие изменения

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

Первым шагом является создание другой ветки, которая накладывается на официальную ветку:

cd ~/workspace/openobject-addons
bzr checkout lp:~openerp/openobject-addons/5.0/ main
cd main
bzr branch --stacked --switch lp:~openerp/openobject-addons/5.0/ lp:~donkirkby/openobject-addons/main

Теперь есть два источника изменений, из которых вам нужно слиться. Во-первых, объединение из функции или ветки исправления ошибок:

cd ~/workspace/openobject-addons/main
bzr merge lp:~donkirkby/openobject-addons/feature-x/
bzr commit -m "Merged feature x"

Конечно, если у вас все еще есть локальная копия функциональной ветви, локальное слияние будет быстрее:

cd ~/workspace/openobject-addons/main
bzr merge ../feature-x
bzr commit -m "Merged feature x"

Во-вторых, иногда вы захотите объединить последние и лучшие из официальной ветки:

cd ~/workspace/openobject-addons/main
bzr merge --remember lp:~openerp/openobject-addons/5.0/
bzr commit -m "Merged from 5.0 branch"

После использования --remember когда вы сливаетесь с официальной ветки, вы можете просто использовать bzr merge самостоятельно слиться с официальной веткой. Если проект использует теги для маркировки точек выпуска, вы можете просмотреть список тегов и объединить их из тега.

cd ~/workspace/openobject-addons/main
bzr tags -d lp:~openerp/openobject-addons/5.0/
bzr merge -r tag:5.0.7rc2

Answer 2

Такая политика (с использованием предложений по слиянию или исправлений) должна быть определена основными разработчиками или сопровождающими самого проекта. Но, как правило, использование отдельных веток для каждого исправления предпочтительнее простых патчей.

• Потому что простые патчи могут устареть, когда развитие магистральной ветки продвигается вперед. Когда вы сохраняете ветку для исправления, вы можете обновить свое исправление в соответствии с последними изменениями в стволе.
• Исправления в ветвях анализировать проще, потому что другие разработчики могут видеть все ваши промежуточные шаги по устранению проблемы или то, как ваше исправление развивалось с течением времени по мере изменения транка.
• Также патчи, прикрепленные к сообщениям об ошибках, часто пропускаются или забываются. В то время как список всех активных предложений по слиянию заметно отображается на странице "Филиалы" каждого проекта.
• Слияние вашего исправления с вашей веткой означает, что история (и аннотации) сохранит ваше имя как автора пути, а не разработчика ядра, который применил ваш патч.

Хранить все исправления в одной ветке не годится для использования в предложении слияния. Но он полезен как таковой для тестирования всех ваших исправлений или использования его в качестве стабильной ветки (например, для собачьей упряжки). Поэтому я бы предложил использовать отдельные (функциональные) ветви для каждого отдельного исправления, подать для них отдельные предложения по слиянию и объединить эти ветви в вашу стабильную ветку, как вы делаете сегодня. Таким образом, вы можете получить полную свободу применения дополнительных изменений к каждому вашему исправлению, а затем снова объединить его с вашей стабильной веткой.

Если вам нужно разделить существующую стабильную ветвь на несколько отдельных веток, вы можете использовать рецепт Джона Майнеля, описанный в его блоге: http://jam-bazaar.blogspot.com/2009/10/refactoring-work-for-review-and-keep.html