[devel] Предложение к изменению в регламент JOIN -> стадии развития мантейнера (сопровождающего)

Ср Мар 20 16:39:04 MSK 2024

Хороший тред.

Я бы предложил, также высказаться самим кандидатам, какие есть проблемы,
как им кажется с их стороны. Так как в этот процесс вовлечены обе стороны.
Я сам [3.6], и я не чувствую себя ущемленным, на практике пакеты можно
доставить в сизиф и без join вообще, через текущих участников. И я тот
который пропадает, на пару месяцев, так как Тима это хобби, а не работа для
меня.

Я бы подсветил 2 проблемы, по мотивации и продвижению с моей стороны:
1. Секретаря нужно больше одного - дольше всего было ожидание проверки и
добавления ключей, около месяца дважды в моём случае, я видимо очень
неудачно переходил по времени, а то и вовсе автоматизацию рутинных
процессов, ещё в руководстве (дописал свою ошибку в руководство в wiki)
2. Стандартизация подходов - переделок мелких по началу было очень много
чисто по стилю даже, так как нет понимания, как надо.

Текущий процесс, вполне себе адекватный и не сложный, но нацелен фокусом на
ментора, как источник скрытых знаний, что в реальности и не даёт быстро
дойти до момента, "я уже собираю пакеты, требуется только Approve от
ментора или кого либо в команде". Но проблемы, как понимаю - закончить этот
процесс то есть 4+, у меня пока опыта там нет.

С моей стороны. Ментор - это хорошо и помогает. Но я, на начальном этапе,
не в обиду своему ментору, пробовал пропихнуть пакеты и через других людей,
уже в Team сначала случайно, потом специально (Rider не знает, но один
пакет проверил мой и он в сизифе). И каждый раз это были новые открытия
относительно всех руководств, которые есть в wiki и от ментора, а так же
есть проблема, что не факт, что использование, как пример другого спека из
репозитория https://github.com/altlinux/specs, пропустят дальше, сегодня.

Поддерживаю Евгения, что отлично было бы, чтобы в команде договорились о
приемлемых рамках:
> Ещё один момент - это соответствие во многом "неписанных" требований,
которые могут быть предъявлены претенденту (кандидату в ALT Linux
Team), тем компетенциям, которым соответствуют или не соответствуют
уже существующие, активные члены команды (собственно, уже прошедшие в
ALT).

По таким рамкам можно было бы написать/дописать linter для пакетов и
применять его для всех. Возможно в целом данные правила и рекомендации
стоит писать, как правила линтера, как для spec, так и для gear в целом
применяя для всех, тем самым содержа их в актуальном состоянии. Больше
автоматизации данного процесса, разгружает ментора проверять spec на
простые ошибки, которые может допускать кандидат, тем самым фокус смещается
на решение реальных проблем с пакетами, а не связанных с стилизацией и
подходами.

--- немного тематического оффтопа про вступление ---

Ещё хотелось бы узнать, какие инструменты вспомогательные можно и нужно
использовать и какие вообще есть, особенно для обновления, какие подходы
для разных языков. Узнать это можно только в общении. Так как наверняка у
ментейнеров со стажем есть не один набор скриптов, упрощающих жизнь себе.
Но из публичных wiki и легко доступных есть только etersoft-build-utils,
наверняка есть и другие, о которых упоминали в багах. Например конвертации
github2spec - удобная тулза и в целом шаблонизатор с 0 под языки, только
нужно прочищать rpmcs другой тулой, чтобы соответствовал каким либо нормам.

PS. Пять копеек про Daedalus и в целом дать Полигон и мотивацию на
попробовать для любопытствующих, не вступая в Team, а после, чем могут
пользоваться всем, подключив целевой пакет себе на машину, аналогично
Fedora Copr. Вариант собрать самому себе - не работает, без возможности
поделиться со всеми. Себе я и без spec собрать могу, просто с сорцов и
пользоваться. А полигон такой, чтобы сделать для других, но не вступая в
Team, даёт мотивацию готовить spec. А оттуда можно в сизиф брать хорошие
варианты, через процесс review. Когда собрали один-два пакета и даже готовы
только их и поддерживать.

PS2: По наименованию - "Кандидат" нормально и сегодня звучит, вы же его и
используете сейчас в переписке большинство.

С уважением,
Антон Пальгунов

On Wed, 20 Mar 2024 at 08:26, Anton Farygin <rider на basealt.ru> wrote:

> On 20.03.2024 11:24, Yuri Sedunov wrote:
> > В Ср, 20/03/2024 в 11:14 +0300, Anton Farygin пишет:
> >> On 20.03.2024 11:13, Yuri Sedunov wrote:
> >>> В Ср, 20/03/2024 в 11:08 +0300, Anton Farygin пишет:
> >>>> On 20.03.2024 10:57, Andrey Savchenko wrote:
> >>>> А именно - халтура заметно растёт от количества задач (пакетов),
> >>>> а
> >>>> вопрос качества можно решать итерационно.
> >>>>
> >>> А пошел бы ты ... пакеты собирать.
> >>>
> >> Действительно, чем команду растить - иди пакеты собирай. Отличный
> >> план.
> >>
> > А ты попробуй и пакеты собирать, и команду растить, желательно молча,
> > ну как я :)
>
> Многих вырастил ?
>
>
> _______________________________________________
> Devel mailing list
> Devel на lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
----------- следующая часть -----------
Вложение в формате HTML было удалено...
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20240320/42e2ac06/attachment-0001.html>