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

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

Историческая справка

Ради чего все это затевалось? Есть разработчики, которые пишут какую-то программу. Есть ещё вопрос зачем они это делают. в зависимочти от этого нам может быть удобно или неудобно с ними взаимодействовать. И нам надо эту программу затолкать в свой репозиторий, оформить её в виде пакета и заставить работать в нашем дистрибутиве (иногда заставить вообще работать).

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

Они же изобрели портируемость операционных систем и портируемость как таковую. Спасибо Кернигану, который надоумил Ричи.

Типы взаимодействий

Стало возможным следующее взаимодействие:

  1. В каждом из немногих уголков круглого земного шара сидят программисты и что-то разрабатывают. Потом записывают на магнитные ленты и везут на конференцию, там кому-нибудь отдают. Происходят такие обмены раз в полгода. Что при этом происходит? Есть два параметра, рассматриваемые в нашем историческом обзоре
    1. Открытость разработки. Между обменами лентами разработка происходит непрозрачно. Люди хотят, чтобы им помогали, именно поэтому они раздают ленточки бесплатно.
    2. Открытость информационного пространства. До тех пор, пока потенциальный участник не растарит ленточку на своем компьютере, он не узнает как шла разработка, докуда она дошла и что делать дальше.
    Какие следствия из такого двойного уровня непрозрачности, свойственного академической разработке?
    1. Релизы, то есть подготовка программного продукта к распространению, происходит редко.
    2. Посколько релизы происходят редко и информационное пространство закрыто, для привлечения других людей к разработке надо довольно много работать над документацией.
  2. Эра FTP. Информационное пространство перестало быть непрозрачным. Люди перестали быть привязанными к

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

  1. Релизы по мере готовности. Именно из этой ситуации породился афоризм "Release early, release often" который боролся с академическими традициями бесконечного допиливания до матового блеска чтобы не опозориться на конференции. Собственно это главное. С этим связано возникновение сизифового труда, когда вы получаете на руки очередной ерли-оффен релиз, начинаете допиливать, пользоваться, и тут получаете новый релиз.
  2. Значимая доля фидбека(обратной связи). В первой эре фидбек происходил редко, и продукты разрабатывались локально. BSD разрабатывался в Беркли. Вы себе представляете свободный продукт, который разрабатывается только в Смоленске? Большинство известных лектору продуктов сильно распределены по миру. Это ещё один миф, с которым долго боролись в хакерском мире -- когда человек сидит и говорит, что он разрабтывает свой продукт в одиночку, а если вы чего-то хотите -- присылайте патчи, я их выкину и напишу свои диффы. Тем не менее эра открытого инф. пространства показала, что эффективно развиваются проекты, в которых обратная связь включалась в процесс разработки. То есть, человек может быть откуда угодно, и вносить свой вклад в проект. Хотя, конечно, бывают ситуации, когда выгодно сидеть локально, а открытое лицензирование -- эт олишь одна и немногих плюшек, которые люди хотят получить.
  3. процесс разработки оставался закрытым. Идея релизов никуда не делась, люди продолжали выкладывать тарболлы. Во-первых по традиции, во-вторых люди хотели что-то отладить, выложить, и начать хакать дальше.
  1. Эра git. Это ситуация, когда ко всему добавляется прозрачность разработки. Почему не открытая? Открытой она и раньше была. Но ситуация, когда в сети содержиться не только исходники, но и вся история проекта, и ваимодействие участнков завязано на сеть, делает её прозрачной. Следствия этой прозрачности:
    1. Что случилось с релизами? Нетрудно проэкстраполировать и сказать, что релизы стали не офтен, а практически ежедневными. Это так и не так. Но тем не менее есть достаточно большое количество людей, для которых главное -- попрограммировать. Они воспринимают перенос в сеть, как индульгенцию от выпуска релизов, каждый коммит -- новая версия программы, они же её только улучшают. Что считать релизом? Вот мы коммитим, мы уверены, что всё улучшили. Размытие понятия релиз. Произошло расслоение программистов на хакеров и разработчиков -- тех кто программирует чтобы програмиировать и тех кто програмимирует, чтобы создать программный продукт. Частая ситуация -- апстрим переехал на гит. Люди выкладывали на фтп тарболлы, в этих тарболлах что-то было, они это делали часто -- три-четыре раза в год. люди перешли на гит. казалось бы, стало только лучше. Если бы. Они вообще перестали отмечать релизы, они просто программируют и коммитят. А что, у них-то все работает. И начинается тайное знание -- надо из вот того коммита собирать, он годный, а следующий все сломал. Деградация, произошедшая от того, что людям интересен процесс программирования, а не результат. С дроугой стороны, люди, которых заботит качетсво программного продукта озаботились -- а что же делать? Очевидно, процесс разработки удобно вести без подчисток. С другой стороны, очень хочется иметь стабильную ветку. Релиз. Для релизов стали выдумывать новые технические термины. Для гита есть ветки. Мы можем в какой-то момент остановить разработку, перенсти в ветку и вносить туда изменения только связанные с безопасностью. Аналог релиза, но более гибкий -- в нём можно делать изменения, но они не должны приводить к изменению функциональности, только к исправлению ошибок. Итого, способы борьбы:
      1. Ветки (стабильная, разработческая, легаси, рок-стейбл)
      2. Средство убедиться, что наш пуш ничего не сломал(автоматическая сборка, возможно даже и автоматическое тестирование.) Особенно это среди наукоемких вещей, типа языков программирования. Если результат работы прошел пачку автоматических тестов мы можем не совсем назвать это релизом, но по крайней мере это программа заработает. Если же мы хотим, чтобы оно ещё и не падало, то есть понятие веток. На самом деле, и раньше так делали -- цвс изобрели давно, понятие бранч -- тоже. просто оно было внутри. У производителей с большой историей, типа интернет консорциума, можно видеть, что разработка сразу идет в несколько веток. Правда, они при этом ничерта не показывают. среда разработки у isc закрыта (онив принципе не рассчитывают на коммьюнити). С появлением системы контроля версий вся эта проблема разрешилась.
      3. теги. Информационные майлстоуны на дереве разработки -- что чего произошло. Некоторые люди помечают тегами релизы.

Этапы сизифового труда

Все ситуации, кроме разве что ситуации номер ноль, наличествуют в современном мире. Все три варианта

Что нужно?

  1. Доступность исходных пакетов.
    1. Например, проект внезапно может переехать. Надо знать актуальный URL.
    2. Может поменять схема публикации -- были тарболыы, стал гитхаб. Начиная от всякой мелочи -- например, поменяли схему версионирования, или стали паковать более лучшим архиватором.
  2. Собираемость. Типичная ситуация. Апстрим любит программировать с помощью копипасты. есть функция, которая вычисляет рост зелёных ёжиков. Вы её попатчили, потому что у вас луна восходит в другое время. Но если люди пишут с помощью копипасты, то патч понадобится ещё для розовых и голубых ежиков, но вам про это никто не сказал. То есть, количество мест приложения патча увеличилось. Ещ бывает, что патч приложился случайно. Ещё собственно собираемость. Например, плозо оформленный файл спецификации и успешность сборки не проверяется. Как выстрелить себе в ногу в рпме? Берёте и запускаете сборку в сабшелле. Результат -- всегда хороший правильный ноль. Итого:
    1. патчи (смыысл)
    2. цельность сборки
    3. доп. файлы. Внезапно, например, образовался целый новый каталог с картинками.
    4. Что ещё проверять -- установка. Типичная ошибка -- вы собрали пакет, он собрался, лог сборки чистый. Далее надо попробовать его установить. Там могли сгенрироваться феерические зависимости.
    5. Дальше более менее очевидные вещи -- насколько то, что у вас получилось соответствует дисциплине оформления пакетов. Есть у вас патч, который раскладывает файлы в нужное место. а на новый кусок апстрима оно не распространяется и он оказывается в старых местах.
    6. Соответствие дисциплине оформления пакетов.
    7. Работспособность.
      1. Если вы ещё не майнтейнер, то наверно вы собираете, чтобы самому пользоваться. Но запускаете его в ограниченном количестве случаев, и никто кроме вас его не тестить.
      2. Вы майнтейнер по требованию -- собрали пакет, но сами им не пользуетесь. Итого, два требования:
      3. Пакет дожен не падать
      4. Насколько отвалились переводы, если это важно. Как правило, переводы запаздывают и, особенно когда их делают сторонние люди, у вас может быть очень хороший, свежий, крутой диспетчер ежеводческой фермы, но на английском со шведским уклоном, и ваши еживоды вас не поймут, когда вы предложите им ЭТО вместо старой доброй Ежик 3.0. Отъехавшие переводы -- повод считать пакет неработспособным.

Всё это намекает нам, что сизифов труд довольно сизифов. Над этим всем надо трудиться. Лектор внезапно видел в интернете дзен паззл -- порядка тысячи абсолютно белых кусочков. Так и здесь, хоть и в меньшей степени.

Какие инструменты на этом пути возможны?

  1. Про патчи уже говорили.
  2. Много инструментов для проверки полиси, собираемости, диагностика дополнительных файлов
  3. make check
  4. Немножко машинерри можно внести в графу доступность. watch файлы, uscan -- умеет зайти на сайт апстрима, проверить наличие новой версии, скачать его, попробовать модифицировать деб файлы в соответствие с этими изменениями. В федоре есть инструмент, которому указываешь урл и спецификацию, и сервис регулярно по ним ходит и шлёт майнтенерам письма "у тебя обновился апстрим, не хочешь ли ты его пересобрать?" Смотрите, чего мы не обсудили, когда говорили про использование технических средств:
    1. мы не говорили про ситуацию, когда апстрим не лежит в распределенной системе контроля версий. Расскажем, почему важна именно она, а как это делается -- перенесем на следующий раз. Когда апстрим использует централизованную систему контроля версия, даже если он её публикует, для майнтенера нет большой разницы между тарболлом и svn checkout. Отличается только тем. что надо знать, чего чекаутить и во -вторых у вас образуются каталоги .svn, в которых лежит непонятный треш. а в ситуации, когда у апстрима распр. система контроля версий вместо того чтобы сделать чекаут, возникает желание сделать вот что.
      1. git clone клонирование в ветку upstream
      2. git branch модификация в отдельной ветке
      3. hack-hack-hack
      4. А когда происходит обновление апстрима, попробовать сделать git pull и манипуляции с ветками.
        1. обновление в ветки upstream.
        2. merge вашей ветки и апстрима.
      Бонус в том, что вы будете видеть весь процесс разработки. Это сильно поможет, когда вы будете пытаться понять, почему патч не прикладываетсяш. Через некоторое время начинаешь понимать. что и с свном можно тоже самое сделать, например, взять гитсвн. Из этого следует, что хранить исходники мы хотим не срцрпме, а в гите, и собирать хотим из гита.

LecturesCMC/PackageMaintaining2013/Conspects/06 (последним исправлял пользователь Allena 2013-04-12 22:58:44)