Вклад в пакет или ветку upstream?
Во время изучения Ubuntu & amp; упаковка, есть одна часть, которая мне не совсем понятна. Итак, допустим, что мы находимся в процессе активной разработки (например, Raring) до замораживания функций, и я хочу поработать над улучшением программы, упакованной для Ubuntu - например, Guake. Я хотел бы исправить ошибку, добавить новую функцию и т. Д. Теперь я вижу два способа сделать это:
- работать над восходящим соединительным каналом lp: guake , отправляя предложение слияния и запросить сопровождающий пакета для Ubuntu для повторной синхронизации пакета
- , работающего над веткой пакета ubuntu: guake , отправив туда мое исправление и позволяя сопровождающему проекта или пакета беспокоиться о пересылке этого исправления upstream или создание исправленной версии guake-ubuntu0 для пакета repo
Один из этих двух подходов лучше? Зависит ли это от ситуации (например, тип вклада - исправление ошибки или новая функция; фаза разработки) и если да, то как? Было бы замечательно, если бы кто-то опытный мог дать еще несколько рекомендаций и советов по этой теме.
При работе в экосистеме GitHub это всегда кажется очень ясным - все сосредоточено вокруг последней версии разработки, и для нее отправляются все запросы извлечения (по крайней мере, я никогда не сталкивался с кем-то, кто отправлял материал для какой-то старой версии 0.7 проекта X). ), в то время как на Launchpad это несоответствие между пакетом и ветвями вверх по течению меня как-то смущает. Я не уверен, что лучше запустить последнюю сборку разработки Ubuntu и покопаться в доступном там исходном коде (через apt-get source <package>), или я должен просто загрузить последний код транка в мою стабильную Ubuntu, внести изменения и посмотреть, смогу ли я каким-то образом можно заставить сопровождающих направить это изменение в пакет (повторная синхронизация, проверка работоспособности сборок на других библиотеках Ubuntu и т. д.)
Я прочитал как старые, так и новые руководства по упаковке, но это все равно оставило меня в замешательстве об этих вопросах.
1 ответ
Вам необходимо концептуально отделить Ubuntu от апстрима, даже если ветка апстрима размещена на Launchpad. Подавляющее большинство пакетов в Ubuntu имеют свою ветвь upstream, полностью размещенную где-то еще (то есть GitHub или SourceForge). Проект upstream, размещенный на Launchpad, может иметь более тесные отношения с Ubuntu, но к нему следует относиться, как к любому другому проекту upstream.
Ubuntu перераспределяет вышестоящее программное обеспечение, обычно внося изменения только тогда, когда это необходимо для интеграции со всем другим программным обеспечением, которое мы поставляем. В большинстве случаев лучшим вариантом является исправление ошибок в исходной версии. Таким образом, решение достигнет большинства людей. Это также уменьшает нагрузку на Ubuntu, так как нет необходимости поддерживать локальные модификации.
Так что в идеале процесс выглядит как ваш первый вариант. Вы исправляете ошибку в апстриме, апстрим выпускает новую версию, а Ubuntu обновляет эту версию. Как вы заметили, вещи не всегда работают таким образом.
Иногда графики выпуска Ubuntu и вышестоящего проекта могут не совпадать. Скажем, вы нашли и исправили ошибку, которую хотели бы увидеть в следующем выпуске Ubuntu, но Ubuntu выйдет через три месяца, и апстрим не знает, когда будет следующий релиз. В такой ситуации лучший подход - это исправить ошибку в исходном потоке, но перенести ее в релиз Ubuntu в виде специального патча для Ubuntu. Это также относится и к исправлению в стабильной версии Ubuntu, где мы, скорее всего, не сможем включить новую версию для основной ветки разработки.
Иногда Ubuntu переносит изменения в апстрим. Если ошибка заключается в этих изменениях, исправление должно идти непосредственно в Ubuntu. Это включает в себя такие вещи, как упаковка.
Новые функции крайне маловероятны в Ubuntu, если только они не были приняты в апстриме. Мы часто принимаем исправления, исправляющие конкретную проблему, до того, как она была применена в апстриме ради более крупного проекта, но мы обычно не хотим отклоняться от апстрима в плане дизайна или функциональности.
Я знаю, что я просто говорю, что это зависит, но это так!