Майнтейнер что это
Перейти к содержимому

Майнтейнер что это

  • автор:

Не только Git…

<i></p>
<p>» width=»16″ height=»16″ /> Пример.</p>
<ul>
<li>Хранение</li>
<li>Версионирование</li>
<li>Работа с историей изменений в виде орграфа</li>
<li>Документирование <em>процесса</em> разработки</li>
<li>Маркировка отдельных коммитов
<ul>
<li>В т. ч. аннотированные и подписанные теги</li>
</ul>
<h3>Организация взаимодействия при совместной разработке</h3>
<ul>
<li>Один публичный репозиторий, т. н. «апстрим»</li>
<li>Разработчики синхронизуются с ним</li>
<li>merge request-ом является электронное письмо с приложенным набором патчей
<ul>
<li>в git есть поддержка этого процесса (gitsend-email)</li>
</ul>
<ul>
<li>Апстрим — один публичный репозиторий, в котором собирается работа всех участников
<ul>
<li>более жёсткая дисциплина «Precious source»: в этот репозиторий делается только pull и review</li>
</ul>
<ul>
<li>В плане использования GIT <em>совпадает с открытой моделью</em></li>
<li>Все дополнительные инструменты разработки могут быть привязаны к git или даже управляться тегами, но в самом git отсутствуют</li>
<li>Выделяют «pull request» (GitHub) или «merge request» (GitLab) в качестве отдельного информационного объекта и обеспечивают (полу)автоматическую его обработку.
<ul>
<li>Важно: понятие merge/pull request в самом git отсутствует, и у него нет чёткого определения</li>
</ul>
<ul>
<li>Один репозиторий для всех</li>
<li>Чёткие конвенции для push и pull</li>
<li>Использование веток в т. ч. для индивидуальной разработки
<ul>
<li>Решённые (под)задачи участники публикуют в том же самом репозитории в специально выделенных личных ветках разработки</li>
</ul>
<p><img decoding=

» width=»16″ height=»16″ /> Ветки и индивидуальные публичные репозитории — ортогональные сущности:

  • Ветки — для эшелонирования работ (например, разработки новой функциональности или разделения на devel — testing — deployment)
  • Индивидуальные публичные репозитории — для разделения областей ответственности по исполнителям
  • В индивидуальном репозитории могут быть какие угодно ветки, например, один и тот же человек может
    1. заниматься разработкой новой фичи — иметь соответствующую ветку в своём публичном репозитории и слать pull-request-ы в ветку newfeature апстрима
    2. заниматься багфиксом релизов и слать pull-request-ы в ветку production апстрима

Работа с несколькими удалёнными репозиториями

  • Общая история
  • Произвольная синхронизация
  • Но: нет встроенных инструментов уведомления
    • (actually, есть — email — но даже он требует инфраструктуры ≠ git: почтовых серверов, email-клиентов и т. п.)

    Информационно-технологическое пространство проекта разработки

    • Общение — списки рассылки, «team discussion», чатики, you name it
      • Как задавать вопросы
      • Как сообщать об ошибках
      • Workflow: open → discuss → solve → close (→ reopen → …)
      • «Patches are welcome!»
      • Инфопространство привязано к конкретным точкам разработки
      • Эффективно в рамках единого хостинга (в остальных случах просто моделируется, например, тредом в списках рассылки)
      • ⇒ может содержать удобные инструменты (например, итерация review)
      • Но: «подход от решения»

      Д/З

      1. Завести один «precious source» репозиторий для merge и публикации проекта и персональные — для разработки (лидеру проекта допустимо вести разработку в отдельной ветке, заводить ещё один репозиотрий ненадо)
      2. Разработать драфт проектного задания;
        • Постановка решаемой задачи: один абзац или список фич
        • Описание предполагаемых инструментов решения: какие сторонние модули будут использоваться, в рамках каких сервисов (если предполагаются)
        • Макет интерфейса (обратите внимание на то, что от проекта требуется локализация ⇒ какой-то интерфейс с человеком должен быть
          • GUI/TUI — общий вид окошек, что в целом они делаю и как попадают из одного в другое
          • Text — команды, диагностика (в общем плане — когда возникает и как посмотреть), режимы работы
          • Поместить проектное задание в README (или README.md) публичного репозиотория
      3. Зарегистрировать публичный репозиторий проекта в качестве вашего персонального issue на странице репозитория PythonDevelopment2022. В issue указать:
        • Короткую формулировку сути проекта
        • Ссылку на публичный репозиторий проекта
        • Список участников проекта в виде:
          1. ФИО, группа (факультет, если не ВМК) и nick, под которым появляются коммиты в репозитории
          2. ФИО, группа (факультет, если не ВМК) и nick, под которым появляются коммиты в репозитории …

          LecturesCMC/PythonDevelopment2022/06_SocialProject (последним исправлял пользователь FrBrGeorge 2022-03-30 09:32:35)

          • Неизменяемая страница
          • Комментарии
          • Информация
          • Прикреплённые файлы
          • MoinMoin Powered
          • Python Powered
          • GPL licensed
          • Valid HTML 4.01
          • Page.execute = 0.008s
          • getACL = 0.020s
          • init = 0.001s
          • load_multi_cfg = 0.000s
          • run = 0.231s
          • send_page = 0.214s
          • send_page_content = 0.025s
          • total = 0.233s

          Взаимодействие на основе патчей. Исследование кода

          Патч или набор с точки зрения GIT — это сериализация коммитов, превращение их в пригодный для передачи формат.

          (если успеем) Организация взаимодействия при совместной разработке

          • Один публичный репозиторий
          • Разработчики синхронизуются с ним, merge request-ом является письмо с приложенным набором патчей
          • Майнтейнер публичного репозитория делает git am и ревью
          • «Precious source» — публичный репозиторий, в который делается только pull
          • Индивидуальные публичные репозитории всех участников
          • Оповещение о готовности индивидуального репозиотрия к merge-у (pull request) со стороны исполнителя
          • Майнтейнер precious source делает git pull и ревью
          • В плане использования GIT совпадает с открытой моделью
          • Все дополнительные инструменты разработки могут быть привязаны к git или даже управляться тегами, но в самом git отсутствуют
            • Например, у понятия merge/pull request даже нет чёткого определения
            • Важно: понятие merge/pull request в самом git отсутствует, и у него нет чёткого определения
            • Один репозиторий для всех
            • Чёткие конвенции для push и pull
            • Использование веток в т. ч. для индивидуальной разработки
            • Важно: раздельных прав доступа на части репозитория в git нет, это или договорённости или дополнительные свойства площадки
            • А ещё это сводит на нет все достоинства DVCS
            • Ветки — для эшелонирования работ (например, разработки новой функциональности или разделения на devel — texting — deployment)
            • Индивидуальные репозитории — для разделения областей ответственности по исполнителям

            Исследование кода

            • Анализ кода: is*()
            • Доступ к исходным текстам: get*()
              • Номера строк, имя файла и т. п.
              • Комментарии, докстринги
              • аннотации
              • Обмазка вокруг встроенного модуля _ast,может меняться от релиза к релизу
              • Можно почитать исходный код (ссылка в начале документации)
              • Там же можно почитать полную БНФ
              • Результат — дерево разбора объектов различного типа (конструкций python)
                • номера строк, исходный текст узла и т. п.

                Пример разбора дерева «на скорую руку»:

                 1  def astformat(node):  2  if isinstance(node, ast.AST):  3  args = []  4  for field in node._fields:  5  value = getattr(node, field)  6  args.append(astformat(value))  7  return f" ''.join(args)>\n"  8  elif isinstance(node, list):  9  return "".join(astformat(x) for x in node)  10  return str(node) 
                • Аналог утилиты diff: python3.10/Tools/scripts/diff.py
                • .unified_diff()
                • .ndiff() (с внутристроковыми изменениями)
                • Сравнение последовательностей
                • TODO
                • Примеры dis.dis()

                Д/З

                1. Написать программу dubfinder.py, которая исследует модули на наличие похожих функций или методов с учётом переименования объектов, наличия произвольных комментариев и изменений в форматировании.
                2. Параметры командной строки: dubfinder.py модуль1 необязательный модуль2 …
                3. Программа выводит пары функций, исходный текст которых «очень похож» (см. ниже критерии)
                4. Вывод: для dubfinder.py spiral (spiral.py):
                $ python3 dubfinder.py spiral spiral.Spiral.__add__ : spiral.Spiral.__sub__ spiral.Spiral.__mul__ : spiral.Spiral.__rmul__
                spiral.Spiral.__add__ spiral2.Spiral.__add__ spiral.Spiral.__init__ spiral2.Spiral.__init__ spiral.Spiral.__iter__ spiral2.Spiral.__iter__ spiral.Spiral.__len__ spiral2.Spiral.__len__ spiral.Spiral.__mul__ spiral.Spiral.__rmul__ spiral.Spiral.__rmul__ spiral2.Spiral.__mul__ spiral.Spiral.__str__ spiral2.Spiral.__str__ spiral.Spiral.__sub__ spiral2.Spiral.__sub__ spiral.Spiral._square spiral2.Spiral._show spiral.main spiral2.master spiral2.Spiral.__add__ spiral2.Spiral.__sub__ spiral2.Spiral.__mul__ spiral2.Spiral.__rmul__
                • Полное совпадение __mul__ и __rmul__ в одном модуле
                • Частичное совпадение __add__ и __sub__ в одном модуле
                • Полное совпадение соответствующих функций и методов в обоих модулях
                • Не используются docstring-и и аннотации
                • Не используются подмодули
                • Не используются инструкции вида from модуль import что-то
                1. Модули разрешено import-тить (с помощью importlib)
                2. Затем рекурсивно просмотрим их с помощью inspect.getmembers() и составим список определённых в них функций
                  • Разрешено игнорировать классы, имя которых начинается с "__" (например, не стоит рекурсивно заходить в что_то.__class__)
                3. Для каждой функции с помощью inspect.getsource() получаем исходный текст.
                4. С помощью ast.parse() превращаем этот текст в дерево разбора (для методов надо предварительно применить textwrap.dedent()
                5. Заменить в дереве все идентификаторы на один (например, на "_")
                  • Я просто прошёлся по ast.walk() и подменил все атрибуты 'name', 'id', 'arg', 'attr' у тех узлов, у которых они были
                6. Собрать обратно препарированный текст с помощью ast.unparse()
                  • Разумеется, комментарии при этом исчезают, а вместо имён везде стоит "_"
                7. Составим словарик вида
                8. Сравним все препараты друг с другом (это n²/2, увы) и для каждой функции подберём наиболее «близкую» с помощью difflib.SequenceMatcher.ratio()
                9. Если это ratio() > 0.95 — пара считается «похожей»

                LecturesCMC/PythonDevelopment2022/05_DiffPatchAST (последним исправлял пользователь FrBrGeorge 2022-03-12 21:00:55)

                • Неизменяемая страница
                • Комментарии
                • Информация
                • Прикреплённые файлы
                • MoinMoin Powered
                • Python Powered
                • GPL licensed
                • Valid HTML 4.01
                • Page.execute = 0.012s
                • getACL = 0.020s
                • init = 0.001s
                • load_multi_cfg = 0.000s
                • run = 0.245s
                • send_page = 0.229s
                • send_page_content = 0.040s
                • total = 0.247s

                ProLibreOffice

                На русском форуме поддержки LibreOffice проскочила информация о том, что LibreOffice будет устанавливаться в МИД РФ в рамках программы «импортозамещения». Причем они там (якобы) проверяют исходники на предмет наличия закладок в коде, затем сформируют сертифицированную сборку, и, видимо, будут это юзать. Вопрос о том, как они будут ставить обновления, и будут ли вообще, остался открытым. Однако сам факт радует, может быть они наймут какую-нибудь контору для осуществления миграции и техподдержки, включая правку багов.

                4 комментария:

                Это вполне нормально. По логике, они нанимают кого-то (или создают свою группу) для осуществления L3-LTS. В рамках его, они получают специально разрабатываемые обновления, которые состоят из бэкпортов тех патчей из мастера, которые выбраны и доработаны (для интеграции со старой версией) майнтейнером. Кроме того, майнтейнер, вероятно, будет сам фиксить проблемы, которые выявятся в процессе эксплуатации заказчиком, и не имеют ещё фиксов в мастере. По условиям лицензии, эти фиксы должны быть открыты, но самый лучший вариант — это когда майнтейнер сразу делает фикс в мастере, и бэкпортит в свой дистр уже оттуда свой же фикс. Тогда в случае последующего перехода (лет через много, на какую-нибудь версию 7.25) ему не понадобится заниматься интеграцией своих старых патчей в сильно изменившуюся кодовую базу.

                В случае, если какой-то фикс ~невозможен без перехода на следующий бейслайн, это и будет обоснованием необходимости такого обновления (с соответствующим аудитом всех промежуточных патчей, что гораздо легче, чем первоначальный аудит). Ответить Удалить

                Уже 15 лет использую и перевожу клиентов только на OpenOffice(LibreOffice). А в последнее время остро возник вопрос о использовании офиса в госструктурах. Нашим клиентам поступило указание проводить политику импортозамещения. А в госреестре нет LibreOffice. И что им порекомендовать, чтобы соблюсти правила игры и остаться на LibreOffice ? Ответить Удалить

                Поступить, как поступают CIB, Collabora и т.д. Создать компанию, чтобы она создала КомпанияОфис, который будет LO с изменённым брендингом. Лицензия позволяет. Лишь бы указывали, что основано на ЛО, а не следовать по пути Дениса Попова. Это уже можно првести в реестр и нормально распространять. И вполне легально получать деньги за сопровождение. Это очень хорошая и полезная для ЛО практика. Удалить

                Записки майнтейнера: resurrection

                В 2010 я стал майнтейнером в ALT Linux: прошёл все этапы процедуры принятия в Team: получил статус кандидата, провёл пробную сборку пакета под руководством ментора damir@ (Дамир Шайхутдиров), получил свой ник (lamp@), почту, сгенерил и зарегистрировал gpg ключи для подписи пакетов и ssh ключи для доступа к git.alt.

                Как так получилось? Всё началось с моего первого знакомства с Debian Linux в 2005 году. Потом были эксперименты с Ubuntu, развесёлые линуксовки местного LUG и наполеоновские планы продвижения Linux в масштабах страны и отдельно взятом Ростове-на-Дону. Тем временем в 2007 компания ALT Linux выиграла всероссийский открытый конкурс на разработку и поставку пакета свободного ПО для школ. Вышел дистрибутив ALT Linux школьный. Начались пилотные внедрения СПО в школах трех российских регионов. И Ростовский LUG решил принять активное участие во всём этом. Мы стали сотрудничать с ALT Linux, посещать школы как официальные представители и помогать внедрять школьный дистрибутив. Даже организовали обучающий семинар для учителей. Подробнее об этом можно прочесть в нашем блоге. Разумеется всё это делалось безвозмездно и в свободное от работы время (обычно по субботам).

                Я также думал о том, что можно предложить школьникам как инструмент для начального изучения программирования. И обнаружил в ALT Linux пакет basic256. Списался с автором-разработчиком Джеймсом Рено (James Reneau) и стал на какое-то время соразработчиком (перевод интерфейса, справки, мелкие улучшения в коде). Само собой — стал майнтейнером. Почти год (с апреля 2010 по январь 2011) старательно сопровождал basic256 и выпустил 7 сборок. Также принял участие в переводе книги Джеймса «Хотите научиться программировать?».

                К сожалению, после бурного 2010го школьный проект в Ростове-на-Дону (и не только) фактически сошел на нет. На первый план вышли более актуальные задачи и я забросил свои обязанности майнтейнера. Однако, последние пару лет подумывал вернуться. И наконец размышления трансформировались в конкретные шаги. Связался с ребятами из ALT, получил добро, заручился поддержкой ментора glebfm@ (Глеб Фотенгауэр-Малиновский) и приступил к делу.

                1. Моё новое старое железо

                К сожалению, старичок ноутбук eMachines M6810, специально купленный для работы c ALT Linux в марте 2010 за 6 тыс. руб, давно отдал концы. Благо в моём хозяйстве обнаружился ноут Samsung P28 (Celeron 1.5Ghz) c 512Mb RAM, без жесткого диска и БП, доставшийся по случаю совершенно бесплатно. Докупил к нему БП и переставил 60Gb хард c почившего eMachines. Установил Simply Linux 7.0.5 — и рабочая лошадка была готова. Да, ещё приобрёл с хорошей скидкой (150 руб) USB WiFi TP-LINK TL-WN723N, поскольку в моём Samsung модуля WiFi не оказалось.

                2. Переход к 8й ветке

                Первое, что посоветовал ментор — обновиться до ветки p8. Что я и проделал, с некоторыми приключениями, которые вряд ли стоят особого внимания. Посетил страницу https://www.altlinux.org/Update и выполнил серию команд:

                $ sudo apt-repo rm all
                $ sudo apt-repo add p8
                $ sudo apt-get update
                $ sudo apt-get dist-upgrade
                $ sudo update-kernel

                Перезагрузился и — вуаля, у меня свеженькая версия:

                $ cat /etc/altlinux-release
                Simply Linux 7.95.0 (Dory)

                В качестве бонуса — заработал USB WiFi TP-LINK. Вообще, к слову, Simply Linux производит очень приятное впечатление. Система хорошо сбалансирована, приемлемо откликается даже на моём слабом железе. Xfce настроен Window-like (лично мне всё равно, но для только пришедшего с Windows удобно). Цветовая гамма приятна для глаз. Плюс прикольная картинка на рабочем столе.

                3. Восстановление доступа

                Ключевой вопрос — что с моими ключами? Понятно, они были на eMachines, но тот хард был переформатирован. Однако ещё тогда, по совету своего первого ментора я сохранил две папки (.gnupg и .ssh) на другом ноутбуке.

                Начнём с gpg ключей. Это два файла (pubring.gpg и secring.gpg) из моей старой папки .gnupg. Эти ключи нужны для подписи srpm и тегов в git. Копирую их из запароленного архива в домашнюю папку и выполняю команду:

                $ gpg —with-fingerprint secring.gpg

                А затем показываю результат ментору (через telegram). Он сравнивает fingerprint моего ключа с тем, который есть в keyring-е ключей членов Team. Отпечаток совпадает. Да, ключи те самые.

                $ gpg —import pubring.gpg
                $ gpg —import secring.gpg
                $ rm *.gpg

                Самое время вспомнить пароль. Создаю пустой файл и пытаюсь его подписать:

                $ touch test_file
                $ gpg -ab test_file

                В ответ gpg запрашивает у меня фразу-пароль. Вот это уже серьёзная проблема. Какой пароль я мог использовать в далёком 2010? Делаю несколько попыток, результат один: Неверная фраза-пароль; попробуйте ещё раз… «Забыть пароль — всё равно что утратить ключи», — тем временем пишет ментор. И тут меня словно осеняет! Пробую свою догадку — срабатывает. Файл подписан и я вспомнил свой пароль!

                Пришло время для ssh ключей (из моей старой папки .ssh). Они нужны для подключения с серверам сборки (gyle.altlinux.org) и синхронизации git-репозитария (gitery.altlinux.org). Снова обращаюсь к своему запароленному архиву, извлекая оттуда два файла (id_dsa и id_dsa.pub). И затем:

                $ ssh-add id_dsa
                $ cp id_dsa .ssh
                $ cp id_dsa.pub .ssh
                $ rm id_dsa*

                Кроме того создаю в .ssh файл (vim ~/.ssh/config) cледующего содержания:

                Host git.alt HostName gitery.altlinux.org Port 222 User git_lamp Host gyle.alt HostName gyle.altlinux.org Port 222 User git_lamp

                После нескольких безуспешных попыток доступа добавляю в ~/.ssh/config первой строкой:

                PubkeyAcceptedKeyTypes +ssh-dss

                Это приходится делать потому что современные openssh-clients считают (справедливо) DSA плохим алгоритмом, его использование нужно разрешать явно. А мои ключи именно DSA (в ближайшее время их надо обновить на RSA по совету ментора). Проверяю доступ командой:

                $ ssh git.alt help
                Enter passphrase for key ‘/home/lamp/.ssh/id_dsa’:

                Ввожу пароль и получаю список доступных команд. Доступ восстановлен, я снова в ALT Linux Team. Следующий шаг — собрать пакет. Но это будет уже новая история…

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *