From: Leonid Krivoshein <klark.devel@gmail.com> To: devel@lists.altlinux.org Subject: Re: [devel] Отсутствие консенсуса в Тим Date: Fri, 16 Jun 2023 13:33:05 +0300 Message-ID: <ccff8409-491f-f44e-1090-4b9cff830bf2@gmail.com> (raw) In-Reply-To: <5ddc7ededa9d3827d20dd95098a517bb@altlinux.ru> Привет! On 6/16/23 10:22, Vitaly Lipatov wrote: > В дополнение к вопросу Алексея Шабалина о прохождении Join я хотел бы > добавить следующие моменты. > > Они о том, кого на самом деле мы приглашаем и ждём в Тим, насколько > хорошо работает Join и насколько Тим является сообществом эгоистов. > > 0. Люди приглашаются в Тим для того, чтобы они могли собирать какой-то > свой пакет («Хотите этот пакет в Сизифе — добро пожаловать в Join»), > то есть зовём всех желающих. А дальше (даже если хотел собирать > маленький пакет с кодом на bash), кандидат должен освоить сборку > shared libs, программ на C++, использование meson и cmake, autotools > само собой. > То есть на самом деле никто не может собирать один пакет в Сизиф, он > предварительно должен стать полноценным мантейнером, хотя ему это > может вовсе не нужно. Полноценный маинтейнер (в твоей интерпретации) должен владеть всем инструментарием сборки и знаниями, которые человеку могут быть совсем не нужны. Такие маинтейнеры Тиму безусловно важны, но затачивать логику джойна исключительно под них, очевидно неправильно. Иначе надо говорить, что ALT Linux Team -- это сообщество исключительно профессиональных сборщиков пакетов. Мне казалось, что этот вопрос ранее уже был решён. Пруф: https://www.youtube.com/watch?v=FtkwU5H9Oqo > 0. Представители компании приглашаются в Тим, когда компания хочет > размещать свой продукт в репозитории (ну или наоборот их уговаривают, > если это Яндекс). При этом задача у такого мантейнера только одна — > отправлять новые версии на сборку и реагировать на проблемы. Пакет он > может собирать давно и для разных rpm-систем. Но нет, он должен стать > полноценным мантейнером. Им предлагается, иногда мы сами собираем, если находим ресурсы. Никого не уговариваем, здесь интерес на их стороне в первую очередь. И как раз с такими проблем возникает меньше, поскольку компетенции в области сборки своих пакетов у них, как правило, хватает, достаточно освоить наши инструменты и policy. Причём, в последнее время количество желающих заджойниться, в том числе, и через нашу партнёрскую сеть совместимости, значительно возросло, так что механизм их одобрения становится особо актуальным. > 1. У нас нет конкретных требований к навыкам мантейнера. Есть какие-то > соответствия ожиданиям и соответствие уровню пакетов в Сизифе. > Понятно, что это сводится к субъективному мнению принимающих, которое > представляется как объективное или консолидированное. Если не ошибаюсь, Георгий Курячий брался делать что-то новое по джойну в части дифференциации и конкретизации требований. Не знаю, чем закончилось. А так, видимо действует старый дефолт: если в баге на джойн написал, "хочу научиться собирать пакеты", то учись. Если бы написал "хочу опакетить скрипт на bash", возможно было бы иначе. > 2. Институт наставников (менторов) не работает, поскольку у > наставников нет подмастерий, они кандидаты. Эти кандидаты каким-то > образом, пособирав дома свои пакеты, должны стать внимательными, > вобрать в себя весь недокументированный опыт (видимо, прочитав много > пёстрых спеков) ведения пакетов в Сизифе, уметь рассуждать о > преимуществах Shared Libs Policy и желательно собирать пакеты из > апстримного git с submodules без поддержки этого в сборочнице > (https://bugzilla.altlinux.org/17914). Если у кого-то что-то с наставником не складывается, нужно искать другого. Постоянная смена наставников говорит о невозможности работы человека в команде. Но в основном опыт проблем с наставниками редкий, и, как правило, проблема у них в дефиците времени. > На мой взгляд, кандидат должен иметь возможность собирать пакеты в > Сизиф как можно раньше (с аппрувом наставником, конечно), чтобы > приобрести тот самый опыт, получить больше замечаний, и прийти на > рецензирование уже с багажом собранных пакетов. Технически сейчас > такая возможность есть, но она не реализуется. Как раз с апрувом сейчас работает, насколько я слышал. Ситуация получается некрасивая для Тима и неудобная для наставника. Потому что пакеты проверяются и апрувятся только одним наставником -- в Сизиф это попадает без двойной проверки, а кандидата получается динамят. > 3. Нет согласия в Тим по поводу применения policy. Полиси как бы есть, > но они никогда не утверждены и исполняются теми, кто хочет их > исправлять. Есть даже механизм утверждения полиси > https://www.altlinux.org/Policy_Policy, но он не работает. В отношении оценки работы кандидата всегда стоит разделять ошибки и рекомендации типа "а я предпочитаю такой вариант". Джойн не должен быть точкой принятия policy и наоборот, отсутствие утверждённого policy не должно быть препятствием для джойна. > 4. Нет механизма выявления консенсуса в Тим по тому или иному вопросу. > Или хотя бы фиксирования двух или трёх равноправных альтернатив. Есть > замаскированный технический лидер (ему всегда можно написать по адресу > placeholder@altlinux.org). Вот эта рассылка в devel@ и есть единственный механизм. > 5. Нет механизма критики мантейнеров. Вообще вся мощь «соответствия > ожиданиям» направлена на кандидатов, чтобы они не прошли Join, такие > же требования к участникам Тим не применяются. Ну почему, критики достаточно и здесь, и в bugzilla. > 6. Примерно ясно, откуда берутся наставники (соглашаются добровольно), > не ясно, откуда берутся рецензенты (назначаются секретарём из списка, > в котором никого нет, потому что механизма попадания в этот список > нет), и не всем понятна формальная роль секретаря (что он исполняет > процедуру, а не принимает решения). Рецензентов остро не хватает, сейчас это главная проблема. > 7. Не ясно, каким образом формируется процедура приёма (Join), в том > числе обязанности менторов и рецензентов. Есть записанные обязанности > секретаря, механизма внесения изменения в которых нет. Возможно, что > секретарь действительно не должен иметь представления о том, как > собираются пакеты, это для него лишнее. > https://www.altlinux.org/Team/Join -- тут и по ссылкам всё есть. IMHO: Нынешняя парадигма джойна не приведёт к экспоненциальному росту Тима даже при весьма высоком спросе из-вне. У человека, быстро и легко прошедшего джойн, напротив, будет стимул набираться опыта и получать навыки в смежных областях, подтверждать их, и через ACL получать новые полномочия. Нужна ступенчатость, нужно разделить навыки опакечивания, работы с апстримным кодом, сборки из исходников, бэкпортирования в стабильные бранчи, закрытия багов, CVE, итд. Сначала нужно побороться за количество, чтобы набрать силы бороться потом за качество. Ну и не должны страдать десятки желающих из-за одного нерадивого ментора (имею ввиду конечно себя), ради которого выстроена такая стена недоверия. Кстати, менторство -- тоже хороший навык для тима, его можно давать, и нужно отзывать. Для начала я бы предложил отказаться от "рецензента для каждого джойна", для каждого он точно не нужен. -- WBR, Leonid Krivoshein.
next prev parent reply other threads:[~2023-06-16 10:33 UTC|newest] Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-06-16 7:22 Vitaly Lipatov 2023-06-16 7:43 ` Ilya Kurdyukov 2023-06-21 11:53 ` Andrey Savchenko 2023-06-16 10:33 ` Leonid Krivoshein [this message] 2023-06-17 7:45 ` Grigory Ustinov 2023-06-21 9:40 ` Sergey Afonin 2023-06-21 10:14 ` Aleksey Novodvorsky 2023-06-21 11:05 ` Sergey Afonin 2023-06-21 12:30 ` Anton Farygin 2023-06-21 12:33 ` Sergey Afonin 2023-06-21 11:22 ` [devel] Отсутствие доверия к сборкам других членов Тим Dmitry V. Levin 2023-06-21 11:28 ` Антон Мидюков 2023-06-21 11:52 ` Yuri Sedunov 2023-06-21 12:04 ` Sergey Afonin 2023-06-21 12:29 ` Aleksey Novodvorsky 2023-06-21 12:39 ` Sergey Afonin 2023-06-23 17:17 ` Vitaly Lipatov 2023-06-23 18:36 ` Sergey Y. Afonin 2023-06-23 18:57 ` Sergey Y. Afonin 2023-06-23 18:58 ` Dmitry V. Levin 2023-06-23 19:41 ` Sergey Y. Afonin 2023-06-23 19:09 ` Vitaly Lipatov 2023-06-23 19:29 ` Denis Medvedev 2023-06-26 9:37 ` Paul Wolneykien 2023-06-23 19:25 ` Ivan A. Melnikov 2023-06-21 16:18 ` Anton Farygin 2023-06-21 12:02 ` [devel] Отсутствие консенсуса в Тим Anton Farygin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=ccff8409-491f-f44e-1090-4b9cff830bf2@gmail.com \ --to=klark.devel@gmail.com \ --cc=devel@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git