Кандидат `kuznetsovam@` ======================= Join: grapheme -------- Url: * `+` Кандидат предусмотрел сборку из апстримного тега. * `+` Кандидат использует `gear-remotes` для сохранения указателя на апстрим. * `?` Не известно, проверял ли кандидат возможность автоматического обновления пакета (`gear-uupdate`, `gear-remotes-uscan`). * `+` Кандидат использует `_unpackaged_files_terminate_build 1`. * `+` Кандидат собирает пакет с тестами. * `+` Кандидат предусмотрел возможность отключения тестов при сборке (`%def_with check`). * `+` Кандидат собирает архитектурно-независимый пакет как `noarch`. * `+` Кандидат подробно заполнил `%description` пакета. * `+` Кандидат использует `BuildRequires(pre)` для дополнительных макросов (с помощью которых выполняется сборка). * `-` Кандидат не использует макрос для указания на стандартную лицензию. * `-` Кандидат не отделяет выпуск новой версии пакета от прочих изменений. Как следствие, изменения не представлены самостоятельно в `git log`, а `%changelog` заполняется полностью вручную. * `-` В пакете предусмотрена возможность сборки документации, однако она не собирается. about-time ---------- Url: Всё абсолютно аналогично предыдущему пакету, включая последовательность комитов. Никаких новых навыков данный пакет не демонстрирует и имеет те же самые недочёты, за исключением сборки документации (отсутствует в пакете). alive-progress -------------- Url: То же. Дополнение: в исходных файлах пакета присутствуют крайне любопытные демонстрационные иллюстрации и анимации, которые следовало бы упаковать как документацию. casr ---- Url: * `+` Кандидатом собран пакет с набором локально упакованных зависимостей (i. e. продемонстрирован vendoring). * `-` Вероятно, лишний `export` для `SKIP_TESTS`. * `-` Исключение `gdb32` из списка тестов выполнено безусловно (ИМХО, должно быть архитектурно-зависимым). * `+` Между тем, продемонстрировано использование конструкции `%ifarch..%endif`. * `?` Нет информации о возможности использования упакованных в Сизиф пакетов вместо локально упакованных зависимостей. * `+` Упакована документация. * `-` Как и в прочих пакетах, кандидат не отделяет выпуск новой версии пакета от прочих изменений. * `+` Продемонстрирован ход сопровождения пакета (обновление до следующей версии). * `-` Кандидат не использует макрос для указания на стандартную лицензию. sqlsmith -------- Url: * `+` Кандидатом продемонстрирован навык сборки пакета на традиционном компилируемом языке (C++) с использованием широко распространённой системы сборки (GNU Autotools). * `-` Недостатки аналогичны указанным ранее. geoipupdate ----------- Url: * `+` Кандидатом продемонстрирована поддержка пакета, ранее сопровождаемого другим мэйнтейнером. * `+` Кандидатом вторично продемонстрирован vendoring. * `?` Как и в предыдущем случае, нет информации о возможности использования упакованных в Сизиф пакетов вместо локально упакованных зависимостей. * `+` Выпуск новой версии отделён от прочих изменений. zoxide ------ Url: То же. aiohttp ------- Url: * `+` Кандидатом продемонстрировано исправление сборки чужого пакета. * `+` Номер версии выбран верно (увеличен только release). * `-` Однако в то же время выпуск новой версии по прежнему не отделён от собственно исправления сборки. hamcrest -------- Url: * `+` Кандидатом снова продемонстрирована поддержка чужого пакета. * `-` Смешение операций по выпуску новой версии пакета с иными изменениями доходят тут до крайности: изменения в `pyproject_deps.json` никак не прокомментированы. libvirt ------- Url: * `+` Кандидатом продемонстрирован точечный импорт изменений (cherry-picking). * `+` Кандидатом продемонстрировано верное оформление закрытия CVE в changelog. * `+` Верное оформление релиза для бранча (с понижением релиза и суффиксом). linkify-it-py ------------- Url: * `+` Кандидатом продемонстрирована сборка пакета в кастомизированной сборочной среде (определённая версия `setuptools` сделана частью исходного пакета). * `-` Выпуск релиза не отделён от этих изменений. * `+` Верное оформление релиза для бранча (с понижением релиза и суффиксом). uc-micro-py ----------- Url: То же. hashcat ------- Url: * `+` Кандидатом продемонстрировано обновление старого пакета (обновление зависимостей, импорт из апстрима, сборка из тега). * `+` Кандидатом продемонстрирован навык сборки пакета на традиционном компилируемом языке (C) с использованием широко распространённой системы сборки (похоже, plain make). * `+` Больши плюсом является демонстрация применения Shared Libs Policy. * `+` Больши плюсом является демонстрация сборки `-devel` пакета. * `-` Имело смысл в данном случае переместить (`git mv`) старый spec-файл в новое место, чтобы ясно отслеживать измнения относительно оригинального. * `+` Кандидат использует `gear-remotes` для сохранения указателя на апстрим. * `?` Не известно, проверял ли кандидат возможность автоматического обновления пакета (`gear-uupdate`, `gear-remotes-uscan`). * `-` Как всегда, кандидат не отделяет выпуск новой версии пакета от прочих изменений (в данном случае их особенно много). * `?` Не известно, рассматривал ли кандидат возможность оставить исходные файлы по старому пути, используя `git subtree`. Заключение ---------- В целом, кандидат продемонстрировал аккуратность в оформлении репозитория и спек-файлов. Видно, что он владеет макросами, специфичными для спеков ALT, а так же основной машинерией `gear`. Нет сомнений в том, что технически он в большинстве случаев будет способен добавить новый пакет в Сизиф. Правда, нужно учитывать, что большинство проектов, которые нам приходится время от времени добавлять в Сизиф, всё ещё написаны на старых, традиционных языках программирования (C, C++), и используют соответствующие им системы сборки (GNU Autotools, `cmake`). Нужно отметить, что в рамках представленной на review работе кандидат предоставил лишь два таких пакета: `sqlsmith` и `hashcat`. С другой стороны, два --- это всё-таки не один пакет. Можно считать, что нужные навыки насчёт традиционной сборки в минимальном объёме продемонстрированы кандидатом успешно, хотя не обошлось без недочётов (перечислены при разборе данных пакетов). Неплохое впечатление оставляет также сборка Python-модулей, продемонстрированная неоднократно (правда, однообразно). Замечу, что процесс вступления в Team не всегда на 100% покрывается производственной необходимостью: есть реальные производственные задачи, не подходящие для демонстрации навыков мэйнтейнера, и наоборот --- есть такие обязательные навыки, которые в данный конкретный момент не участвуют в решении производственных задач. Второй момент, на который следует обратить даже большее внимание, это --- отсутствие демонстрации такой традиционной для мэйнтейнера деятельности, как поиск и прикладывание патчей. Не будет преувеличением сказать, что в полной мере задача _сопровождения_ пакетов выражается именно в умелом оперировании патчами. Сборка же набора исходных файлов --- это всё-таки только сборка, а не сопровождение пакета как таковое. Я считаю, что ментору следовало предусмотреть подобную задачу для своего подопечного. Как необходимый минимум --- сборка из тега + патч, исправляющий сборку или добавляющий ALT-специфичные изменения. Как максимум: указанный минимум + адаптация патча для следующей версии оригинальных исходных файлов. Отдельно отмечу, что очень порадовала демонстрация понимания и применения Shared Libs Policy, а также разделение пакетов на runtime и devel (пакет `hashcat`). В-четвёртых, хочу прокомментировать своё замечание, чаще всего указанное в разборе пакетов выше: оформление выпуска новой версии отдельным комитом. Почему отдельным? Потому, что любое изменение, не касающееся `%changelog`, может в дальнейшем быть отозвано (`git revert` или его аналог), в то время как однажды добавленная запись в `%changelog` никогда уже оттуда не отзывается (конечно, только в том случае, если версия пакета действительно была выпущена). По этой причине я настоятельно рекомендую оформлять изменения, содержащие `Version`, `Release` и новую запись `%changelog` отдельным комитом (например, с помощью команды `gear-commit`). Конечно, это лишь рекомендация. Что совсем не было продемонстрировано? Сборка системной службы (сервиса). А ведь рано или поздно придётся такой пакет собрать. Упаковка служб связана с распространёнными ошибками в отношении пропуска `%post_service` и `%preun_service`. Немаловажным тут является необходимость предусмотреть перезапуск демона при обновлении пакета. Или другая крайность: пакет может запускать службу сразу после установки (а это опасно). Далее, поскольку мы не отказываемся от поддержки SysV-init систем, полезно было бы продемонстрировать упаковку init-скрипта, который в современном мире часто приходится искать отдельно либо писать самому. Но бывают и обратные ситуации --- приходится искать или писать systemd-юнит. **Решение:** В дополнение к уже представленным сборкам, кандидату надлежит продемонстрировать пакет с системной службой (демоном). Не лишним будет в том же пакете показать сборку upstream + patch. Учитывая все продемонстрированные кандидатом навыки, я не сомневаюсь в скорейшем успехе.