On 17.03.2024 10:22, Alexey V. Vissarionov wrote:
> Good ${greeting_time}!
>
> On 2024-03-16 12:43:41 +0200, Dmitry V. Levin wrote:
>
> >> Для данной стадии предлагается выбрать соответствующее название
> > В принципе, если консенсуса по названию не будет, то не в названии
> > дело, хотя название было бы, наверное, удобнее нынешних номеров.
>
> Вижу три уровня: кандидат, стажер, участник.
Ну или в английском варианте:
Candidate, Intern and Participant
Вместо последнего можно (и лучше) использовать уже привычный
сопровождающий / maintainer
Мне такой вариант нравится.
On 16.03.2024 13:43, Dmitry V. Levin wrote: > On Thu, Mar 14, 2024 at 09:16:05PM +0300, Anton Farygin wrote: > [...] >> Предлагаю считать кандидата на стадии 4.0 уже вступившим в команду, но >> имеющим некоторые ограничения в правах. А именно: >> >> - он может отправлять изменения только к тем пакетам, в ACL которых он >> присутствует; >> >> - он может отправлять новые, приналежащие @nobody или @everybody пакеты >> только после review и approve от прошедших стадию 4.2 ментейнеров; >> >> - в ACL новых (или принадлежащих @nobody) пакетов, отправляемых таким >> ментейнером лидером устанавливается тот, кто делал approve; > По сути речь идёт о том, что мы как team уже готовы доверить новым > кандидатам, а что - ещё не готовы. Это предложение, по видимому, неявно > постулирует, что мы готовы доверять новым кандидатам отдельные пакеты, но > не готовы сразу доверить любой пакет с открытым acl, а захочет ли и сможет > ли кандидат добиться такого доверия - это вопрос индивидуальный. Да, спасибо. Всё верно. Думаю что за счёт групп может оказаться так, что кандидату можно будет доверять не только пакеты, но и более широкое участие. > >> - может присутствовать в ACL только в качестве соучастника (не может >> быть лидером и не может оставаться один); > Не очевидно, какая могла бы быть польза в этом ограничении. Это вытекает из того, что в ACL пакета лидером будет вставать тот, кто сделал review пакета кандидата. Цель простая - пока кандидат не станет полноценным ментейнером за его пакеты должен вмести с ним отвечать какой-то ментор. > >> при этом ментор фактически завершает свою работу и в дальнейшем росте >> такого ментейнера в команде становятся все участники. > Мне кажется, упразднение ментора на этой стадии не будет полезно. Хотя > сейчас, насколько я вижу, это уже фактически происходит, не считаю это > хорошей практикой. Если сейчас ментор зачастую спихивает менторство на > конкретного рецензента, то в предложенной схеме менторство будет > перекладываться на всю team, что, скорее всего, дополнительно затруднит > интеграцию кандидатов, поскольку в team сейчас фактически не видно никаких > механизмов интеграции кандидатов. Да, согласен. Но я хотел в этом избежать ментор-лок ситуаций, когда кандидат завязан на одного ментора фактически или не выполняющего менторских обязанностей или выполняющего их плохо. > >> Для данной стадии предлагается выбрать соответствующее название и я > В принципе, если консенсуса по названию не будет, то не в названии дело, > хотя название было бы, наверное, удобнее нынешних номеров. А тебе какой вариант больше понравился ?
On Friday, 15 March 2024 19:08:28 MSK Evgeny Sinelnikov wrote: [...] > чтобы не > тащить в сборочное окружение лишние пакеты с их зависимостями. Тогда > цель становится понятной. Но это довольно тогда большая работа. Эта "большая работа" не сложнее перекладывания из пустого в порожнее. > У нас > и без неё много всего лишнего тянется в сборочное окружение. Эту > задачу нужно решать более комплексно, я думаю. Уж точно не с dbusxml > файлов начинать стоит. Лучше с него, чем с перекладывания на здоровую голову. -- Regards, Sergey.
On Friday, 15 March 2024 19:08:28 MSK Evgeny Sinelnikov wrote: > Добрый вечер, > > поскольку суть обсуждения явно не заявлена, попытаюсь её сформулировать. [...] > На мой взгляд это совершенно бесполезно Я эту строку выше вижу, как полное описание API нового Alterator. [...] -- Regards, Sergey.
Стухло твое задание. Нужен отдельно стоящий 3.1.0 в сизифе уже сейчас.
В Чт, 14/12/2023 в 17:11 +0300, Andrey Cherepanov пишет:
>
> Задание 336453 расшарено
> Необходимо пересобрать (с freerdp3.pc):
> gnome-connections aris
> gnome-remote-desktop aris
> guacamole-server shaba @everybody
> remmina shaba @qa
> vinagre aris shaba
> weston aris
>
--
Yuri N. Sedunov
Good ${greeting_time}! On 2024-03-16 12:43:41 +0200, Dmitry V. Levin wrote: >> Для данной стадии предлагается выбрать соответствующее название > В принципе, если консенсуса по названию не будет, то не в названии > дело, хотя название было бы, наверное, удобнее нынешних номеров. Вижу три уровня: кандидат, стажер, участник. -- Alexey V. Vissarionov gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net
[-- Attachment #1: Type: text/plain, Size: 6836 bytes --] Пока суд да дело: On Thu, Mar 14, 2024 at 03:20:17PM +0000, Girar awaiter (arseny) wrote: > https://git.altlinux.org/tasks/342669/logs/events.3.1.log > > subtask name aarch64 i586 ppc64le x86_64 > У нижеследующих пакетов есть зависимость на iproute2 и arepo-подпакеты, что до сей поры приводило к тому, что (зачем-то?) для этих последних генерировались зависимости на i586-iproute2. > #200 NetworkManager 12:21 7:37 14:20 7:01 > #300 aircrack-ng 1:35 57 1:51 54 > #400 dpdk 18:17 7:42 13:39 9:01 > #500 libvirt 6:59 5:09 7:23 4:51 > #600 marss-riscv 5:57 3:07 5:52 2:49 > #700 netplan 56 29 1:00 28 > #1000 open-vm-tools 3:47 2:13 - 2:04 > #1100 vde2 1:58 1:19 2:06 1:17 В iproute2 6.8.0 апстрим закопал[1][2] %_libdir/tc/m_{ipt,xt}.so, и i586-iproute2 стал более не нужен. Пришлось пересобрать всех, кто зачем-то якобы от него зависел. [1] https://lwn.net/ml/netdev/20231221213105.476630-1-jhs@mojatatu.com/ [2] https://lore.kernel.org/netdev/170467862324.24659.6040892717113322740.git-patchwork-notify@kernel.org/ Если нет возражений, прошу посмотреть и одобрить. Судя по концу лога, вешать одобрение, строго говоря, требуется только для самого iproute2. > 2024-Mar-14 13:24:16 :: task #342669 for sisyphus resumed by arseny: > 2024-Mar-14 13:24:16 :: message: Rebuild unmet arepo-generated dependencies > #100 build 6.8.0-alt1 from /people/arseny/packages/iproute2.git fetched at 2024-Mar-13 23:17:24 > #200 build 1.46.0-alt1 from /gears/N/NetworkManager.git fetched at 2024-Mar-14 13:22:45 from sisyphus > #300 build 1.7-alt3 from /gears/a/aircrack-ng.git fetched at 2024-Mar-14 13:22:47 from sisyphus > #400 build 22.11.3-alt2 from /gears/d/dpdk.git fetched at 2024-Mar-14 13:22:49 from sisyphus > #500 build 9.8.0-alt4 from /gears/l/libvirt.git fetched at 2024-Mar-14 13:22:53 from sisyphus > #600 build 4.1a-alt2 from /gears/m/marss-riscv.git fetched at 2024-Mar-14 13:22:55 from sisyphus > #700 build 0.106-alt1 from /gears/n/netplan.git fetched at 2024-Mar-14 13:22:55 from sisyphus > #1000 build 12.3.5-alt1 from /gears/o/open-vm-tools.git fetched at 2024-Mar-14 13:22:56 from sisyphus > #1100 build 2.3.3-alt1 from /gears/v/vde2.git fetched at 2024-Mar-14 13:22:57 from sisyphus > 2024-Mar-14 13:24:16 :: created build repo > 2024-Mar-14 13:24:17 :: [i586] #100 iproute2.git 6.8.0-alt1: build start > 2024-Mar-14 13:24:17 :: [ppc64le] #100 iproute2.git 6.8.0-alt1: build start > 2024-Mar-14 13:24:17 :: [aarch64] #100 iproute2.git 6.8.0-alt1: build start > 2024-Mar-14 13:24:17 :: [x86_64] #100 iproute2.git 6.8.0-alt1: build start > 2024-Mar-14 13:24:32 :: [i586] #100 iproute2.git 6.8.0-alt1: build OK (cached) > 2024-Mar-14 13:24:32 :: [i586] #200 NetworkManager.git 1.46.0-alt1: build start > 2024-Mar-14 13:24:33 :: [x86_64] #100 iproute2.git 6.8.0-alt1: build OK (cached) > 2024-Mar-14 13:24:33 :: [x86_64] #200 NetworkManager.git 1.46.0-alt1: build start > 2024-Mar-14 13:24:50 :: [aarch64] #100 iproute2.git 6.8.0-alt1: build OK (cached) > 2024-Mar-14 13:24:51 :: [aarch64] #200 NetworkManager.git 1.46.0-alt1: build start > 2024-Mar-14 13:24:57 :: [ppc64le] #100 iproute2.git 6.8.0-alt1: build OK (cached) > 2024-Mar-14 13:24:58 :: [ppc64le] #200 NetworkManager.git 1.46.0-alt1: build start > <...> > 2024-Mar-14 14:24:35 :: build check OK > warning (#300): aircrack-ng-devel-1.7-alt3.x86_64.rpm should be .noarch.rpm > warning (#500): libvirt-client-qemu-9.8.0-alt4.x86_64.rpm should be .noarch.rpm > warning (#500): libvirt-lxc-9.8.0-alt4.x86_64.rpm should be .noarch.rpm > 2024-Mar-14 14:26:52 :: noarch check OK > 2024-Mar-14 14:26:55 :: plan: src +9 -9 =19105, aarch64 +122 -122 =32071, i586 +121 -121 =31618, noarch +9 -9 =19714, ppc64le +115 -115 =31143, x86_64 +126 -126 =32958 > #100 iproute2 6.7.0-alt1 -> 6.8.0-alt1 > Wed Mar 13 2024 Arseny Maslennikov <arseny@altlinux> 6.8.0-alt1 > - 6.7.0 -> 6.8.0. > 2024-Mar-14 14:27:44 :: patched apt indices > 2024-Mar-14 14:27:54 :: created next repo > 2024-Mar-14 14:28:03 :: duplicate provides check OK > 2024-Mar-14 14:28:40 :: dependencies check OK > 2024-Mar-14 14:29:08 :: [x86_64 i586 aarch64 ppc64le] ELF symbols check OK > <...> > 2024-Mar-14 15:17:01 :: [x86_64-i586] plan: #50 +50 -51 =10675 > 2024-Mar-14 15:18:57 :: [x86_64-i586] arepo build OK > 2024-Mar-14 15:19:17 :: [x86_64-i586] generated apt indices > 2024-Mar-14 15:19:19 :: [x86_64-i586] created next repo > 2024-Mar-14 15:19:31 :: [x86_64-i586] dependencies check OK > 2024-Mar-14 15:19:34 :: gears inheritance check OK > 2024-Mar-14 15:19:35 :: srpm inheritance check OK > girar-check-perms: access to iproute2 DENIED for arseny: does not belong to approved builders list: @core vt > check-subtask-perms: #100: iproute2: Operation not permitted > girar-check-perms: access to NetworkManager ALLOWED for arseny: rebuild is allowed by default > check-subtask-perms: #200: NetworkManager: allowed for arseny > girar-check-perms: access to aircrack-ng ALLOWED for arseny: project leader welcomes random builders > check-subtask-perms: #300: aircrack-ng: allowed for arseny > girar-check-perms: access to dpdk ALLOWED for arseny: project leader welcomes random builders > check-subtask-perms: #400: dpdk: allowed for arseny > girar-check-perms: access to libvirt ALLOWED for arseny: project leader welcomes random builders > check-subtask-perms: #500: libvirt: allowed for arseny > girar-check-perms: access to marss-riscv ALLOWED for arseny: project leader welcomes random builders > check-subtask-perms: #600: marss-riscv: allowed for arseny > girar-check-perms: access to netplan ALLOWED for arseny: project leader welcomes random builders > check-subtask-perms: #700: netplan: allowed for arseny > girar-check-perms: access to open-vm-tools ALLOWED for arseny: rebuild is allowed by default > check-subtask-perms: #1000: open-vm-tools: allowed for arseny > girar-check-perms: access to vde2 ALLOWED for arseny: project leader welcomes random builders > check-subtask-perms: #1100: vde2: allowed for arseny > 2024-Mar-14 15:19:36 :: acl check FAILED > 2024-Mar-14 15:20:02 :: created contents_index files > 2024-Mar-14 15:20:13 :: created hash files: aarch64 i586 noarch ppc64le src x86_64-i586 x86_64 > 2024-Mar-14 15:20:16 :: task #342669 for sisyphus EPERM [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #1: Type: text/plain, Size: 8408 bytes --] On Sat, Feb 03, 2024 at 12:38:44AM +0300, Arseny Maslennikov wrote: > === Сначала о пакетах === > > Во-первых, не хотелось бы обновлять сотню пакетов в одной > транзакции с пакетом filesystem, содержащим вместо /bin, /sbin, > ... симлинки. Чтобы этого избежать, надо добиться, чтобы пакеты, > кладущие что-либо в эти каталоги (вне %_prefix), > устанавливались и на merged, и на unmerged, и на split[1]. > Для этого планируется ввести brp-модуль, который при сборке > пакета, если в %buildroot лежит что-то в соотв. каталогах вне > префикса, создаст копию этого файла в аналогичном месте под > префиксом. > Можно было бы вместо копии делать ссылку, но оказалось, что нет: > * (упакованные в cpio) симлинк поверх файла или файл поверх симлинка нельзя > установить на merged-usr, т. е. поверх друг друга; > * (упакованные в cpio) хардлинки нельзя установить на > split-usr-иерархию, потому что они придутся на разные ФС, и > rpm не сможет их расщепить (изготовить одинаковые inode). > Это позволило снизить количество пакетов с файлами в /bin и > /sbin, для которых потребуются ручные изменения, с 90 до ~20. > > [1] https://www.altlinux.org/Usrmerge#%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9 Почти реализовано (ждём install checks). https://git.altlinux.org/tasks/327286 Можно коммитить задание, как только будет готово к коммиту и при отсутствии иных возражений. Прошу одобрений от: girar-check-perms: access to rpm-build DENIED for arseny: approved builders list: @core imz at vt girar-check-perms: access to rpm DENIED for arseny: approved builders list: @core at imz vt girar-check-perms: access to gzip DENIED for arseny: approved builders list: @core girar-check-perms: access to coreutils DENIED for arseny: approved builders list: @core girar-check-perms: access to gawk DENIED for arseny: approved builders list: @core girar-check-perms: access to util-linux DENIED for arseny: approved builders list: legion boyarsh @core girar-check-perms: access to findutils DENIED for arseny: approved builders list: @core girar-check-perms: access to bzip2 DENIED for arseny: approved builders list: @core girar-check-perms: access to iputils DENIED for arseny: approved builders list: sem ender girar-check-perms: access to acct DENIED for arseny: approved builders list: @core @qa girar-check-perms: access to chrooted DENIED for arseny: approved builders list: @core girar-check-perms: access to genromfs DENIED for arseny: approved builders list: @core girar-check-perms: access to kbd DENIED for arseny: approved builders list: legion @core glebfm@ помог провести тестовую пересборку репозитория, получающегося из этого задания, которая помогла выявить и исправить 2 ошибки. 5 новых пакетов не пересобрались по каким-то своим причинам; в окружении задания выше они пересобрались. > Мы ожидаем, что после появления rpm-build с новым brp-модулем в > репозитории немногочисленные исправленные пакеты будут собраны в > Sisyphus в своих индивидуальных заданиях (транзакциях), не > создавая на сборочнице заторов на CI-проверках каждого > подзадания. > > === Теперь о миграции === Как только закоммитим задание выше, можно будет приступать к тому, что ниже. Думаю, понадобится тестовая пересборка с filesystem 3, чтобы узнать про будущие вероятные проблемы, которые ещё не выскочили. > После того, как все (допускаю, что за ничтожными исключениями) > пересобираемые пакеты в Sisyphus станут устанавливаться и на > старые иерархии, и на новые, настанет время собрать в > репозиторий пакет filesystem (версией > 3) уже с симлинками > вместо каталогов. > > Это самая сложная часть процесса: > * пакеты должны будут пересобираться в merged-иерархии, сейчас > мы это проверяем вручную; > * чтобы он мог установиться на уже заполненный корень, > например, в установленную unmerged-систему, симлинки уже > должны быть расставлены на месте каким-то иным инструментом > перед тем, как rpm распакует пакет. > > Мне известно два метода решения этой задачи: один реализуем точно, > а другой умозрительно. > * Переносить файлы и создать симлинки специальным инструментом[2] > прямо перед распаковкой пакета filesystem: либо в %pre этого > пакета, либо в %pretrans. В качестве дополнительной меры > предохранения попробовать добиться, чтобы filesystem > в rpm-транзакции стоял позже, чем другие затронутые пакеты. > * (умозрительный способ) Добиться того, чтобы на системах с > unmerged-иерархией filesystem > 3 не попадал в rpm-транзакцию, а > специальный инструмент запускать в filetrigger после > транзакции, когда выяснится (каков критерий?), что все пакеты > обновлены до версий, подготовленных как описано в предыдущей > секции, и конфликтов при копировании больше не будет. > Инструмент для слияния сводится к cp -Tal, мерам обеспечения > атомичности замен каталогов на симлинки (файлы по своим путям > должны быть доступны в любой момент времени), вариантам обхода > многочисленных особых случаев в старых пакетах, с которыми сама > команда cp -Tal не справится. При втором методе (в posttrans) > он, в теории, может быть устроен проще, и проще доказать, что > перенос не может сломаться ни при каком состоянии релевантного > поддерева ФС. > > [2] https://packages.altlinux.org/en/sisyphus/srpms/usrmerge/ > > Я пока что предполагаю, что нам придётся пользоваться первым > методом, но не исключаю, что удастся придумать реализацию > второго. > > Предлагаю обсуждать процесс тут, если есть что обсуждать. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --]
16.03.2024 12:39, Denis Medvedev пишет: > On Sat, 16 Mar 2024 12:28:00 +0300 > Anton Farygin <rider@basealt.ru> wrote: > >> On 16.03.2024 11:38, Denis Medvedev wrote: >>> On Sat, 16 Mar 2024 11:27:23 +0300 >>> Aleksey Novodvorsky <aen@basealt.ru> wrote: >>> >>>> сб, 16 мар. 2024 г. в 10:59, Anton Farygin <rider@basealt.ru>: >>>>> On 16.03.2024 04:47, Grigory Ustinov wrote: >>>>>>> - не имеет права голоса в принятии технических решений (но >>>>>>> естественно может принимать участие в обсуждениях); >>>>>> И сейчас не имеет, но может обсуждать. >>>>>> >>>>> А у нас сейчас нет вообще формального голосования. Этот пункт, >>>>> скорее, написан на будущее. >>>> При всех возможных проблемах с голосованием, которые мы наблюдаем, >>>> например, у коллег из Debian, >>>> это будущее хорошо бы приблизить. Есть предложения? >>> Создавать пакет в сизиф "join-<кандидат ник>" и на таске с этим >>> пакетом ставить апрувы/дисапрувы. При наличии апрува от ревьюера и >>> ментора таск проходит - кандидат считается в тиме. Остальные могут >>> голосовать путем апрува/дисапрува этого таска с комментариями. >> Денис, нет - речь не про голосования за вступление, речь про >> голосования для принятия решений, и не только технических. > В принципе можно так же - апрувы/дисапрувы на пакет специального вида > (с содержимым, касающимся вопроса о котором идет голосование). > Но тайное голосование при этом невозможно. Я не знаток кода сборочницы, но логически кажется несложным добавить новый режим таска, что-то вроде --vote, в котором ники можно было бы закрывать плюсиками, минусиками, да хоть звёздочками. > _______________________________________________ > Devel mailing list > Devel@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/devel
On Thu, Mar 14, 2024 at 09:16:05PM +0300, Anton Farygin wrote: [...] > Предлагаю считать кандидата на стадии 4.0 уже вступившим в команду, но > имеющим некоторые ограничения в правах. А именно: > > - он может отправлять изменения только к тем пакетам, в ACL которых он > присутствует; > > - он может отправлять новые, приналежащие @nobody или @everybody пакеты > только после review и approve от прошедших стадию 4.2 ментейнеров; > > - в ACL новых (или принадлежащих @nobody) пакетов, отправляемых таким > ментейнером лидером устанавливается тот, кто делал approve; По сути речь идёт о том, что мы как team уже готовы доверить новым кандидатам, а что - ещё не готовы. Это предложение, по видимому, неявно постулирует, что мы готовы доверять новым кандидатам отдельные пакеты, но не готовы сразу доверить любой пакет с открытым acl, а захочет ли и сможет ли кандидат добиться такого доверия - это вопрос индивидуальный. > - может присутствовать в ACL только в качестве соучастника (не может > быть лидером и не может оставаться один); Не очевидно, какая могла бы быть польза в этом ограничении. > при этом ментор фактически завершает свою работу и в дальнейшем росте > такого ментейнера в команде становятся все участники. Мне кажется, упразднение ментора на этой стадии не будет полезно. Хотя сейчас, насколько я вижу, это уже фактически происходит, не считаю это хорошей практикой. Если сейчас ментор зачастую спихивает менторство на конкретного рецензента, то в предложенной схеме менторство будет перекладываться на всю team, что, скорее всего, дополнительно затруднит интеграцию кандидатов, поскольку в team сейчас фактически не видно никаких механизмов интеграции кандидатов. > Для данной стадии предлагается выбрать соответствующее название и я В принципе, если консенсуса по названию не будет, то не в названии дело, хотя название было бы, наверное, удобнее нынешних номеров. -- ldv
On Sat, 16 Mar 2024 12:28:00 +0300
Anton Farygin <rider@basealt.ru> wrote:
> On 16.03.2024 11:38, Denis Medvedev wrote:
> > On Sat, 16 Mar 2024 11:27:23 +0300
> > Aleksey Novodvorsky <aen@basealt.ru> wrote:
> >
> >> сб, 16 мар. 2024 г. в 10:59, Anton Farygin <rider@basealt.ru>:
> >>> On 16.03.2024 04:47, Grigory Ustinov wrote:
> >>>>> - не имеет права голоса в принятии технических решений (но
> >>>>> естественно может принимать участие в обсуждениях);
> >>>> И сейчас не имеет, но может обсуждать.
> >>>>
> >>> А у нас сейчас нет вообще формального голосования. Этот пункт,
> >>> скорее, написан на будущее.
> >> При всех возможных проблемах с голосованием, которые мы наблюдаем,
> >> например, у коллег из Debian,
> >> это будущее хорошо бы приблизить. Есть предложения?
> >
> > Создавать пакет в сизиф "join-<кандидат ник>" и на таске с этим
> > пакетом ставить апрувы/дисапрувы. При наличии апрува от ревьюера и
> > ментора таск проходит - кандидат считается в тиме. Остальные могут
> > голосовать путем апрува/дисапрува этого таска с комментариями.
>
> Денис, нет - речь не про голосования за вступление, речь про
> голосования для принятия решений, и не только технических.
В принципе можно так же - апрувы/дисапрувы на пакет специального вида
(с содержимым, касающимся вопроса о котором идет голосование).
Но тайное голосование при этом невозможно.
On 16.03.2024 11:38, Denis Medvedev wrote:
> On Sat, 16 Mar 2024 11:27:23 +0300
> Aleksey Novodvorsky <aen@basealt.ru> wrote:
>
>> сб, 16 мар. 2024 г. в 10:59, Anton Farygin <rider@basealt.ru>:
>>> On 16.03.2024 04:47, Grigory Ustinov wrote:
>>>>> - не имеет права голоса в принятии технических решений (но
>>>>> естественно может принимать участие в обсуждениях);
>>>> И сейчас не имеет, но может обсуждать.
>>>>
>>> А у нас сейчас нет вообще формального голосования. Этот пункт,
>>> скорее, написан на будущее.
>> При всех возможных проблемах с голосованием, которые мы наблюдаем,
>> например, у коллег из Debian,
>> это будущее хорошо бы приблизить. Есть предложения?
>
> Создавать пакет в сизиф "join-<кандидат ник>" и на таске с этим пакетом
> ставить апрувы/дисапрувы. При наличии апрува от ревьюера и ментора таск
> проходит - кандидат считается в тиме. Остальные могут голосовать путем
> апрува/дисапрува этого таска с комментариями.
Денис, нет - речь не про голосования за вступление, речь про голосования
для принятия решений, и не только технических.
On 16.03.2024 11:27, Aleksey Novodvorsky wrote:
> сб, 16 мар. 2024 г. в 10:59, Anton Farygin <rider@basealt.ru>:
>> On 16.03.2024 04:47, Grigory Ustinov wrote:
>>>> - не имеет права голоса в принятии технических решений (но
>>>> естественно может принимать участие в обсуждениях);
>>> И сейчас не имеет, но может обсуждать.
>>>
>> А у нас сейчас нет вообще формального голосования. Этот пункт, скорее,
>> написан на будущее.
> При всех возможных проблемах с голосованием, которые мы наблюдаем,
> например, у коллег из Debian,
> это будущее хорошо бы приблизить. Есть предложения?
>
Я уже достаточно давно думаю над этим, как раз наблюдая проблемы с
голосованием у коллег.
Если бы были предложения по реализации, то я уже их давно бы озвучил.
Нет, к сожалению пока предложений нет.
Может быть у кого-то есть идеи ?
On Sat, 16 Mar 2024 11:27:23 +0300
Aleksey Novodvorsky <aen@basealt.ru> wrote:
> сб, 16 мар. 2024 г. в 10:59, Anton Farygin <rider@basealt.ru>:
> >
> > On 16.03.2024 04:47, Grigory Ustinov wrote:
>
> > >> - не имеет права голоса в принятии технических решений (но
> > >> естественно может принимать участие в обсуждениях);
> > > И сейчас не имеет, но может обсуждать.
> > >
> > А у нас сейчас нет вообще формального голосования. Этот пункт,
> > скорее, написан на будущее.
>
> При всех возможных проблемах с голосованием, которые мы наблюдаем,
> например, у коллег из Debian,
> это будущее хорошо бы приблизить. Есть предложения?
Создавать пакет в сизиф "join-<кандидат ник>" и на таске с этим пакетом
ставить апрувы/дисапрувы. При наличии апрува от ревьюера и ментора таск
проходит - кандидат считается в тиме. Остальные могут голосовать путем
апрува/дисапрува этого таска с комментариями.
сб, 16 мар. 2024 г. в 10:59, Anton Farygin <rider@basealt.ru>: > > On 16.03.2024 04:47, Grigory Ustinov wrote: > >> - не имеет права голоса в принятии технических решений (но > >> естественно может принимать участие в обсуждениях); > > И сейчас не имеет, но может обсуждать. > > > А у нас сейчас нет вообще формального голосования. Этот пункт, скорее, > написан на будущее. При всех возможных проблемах с голосованием, которые мы наблюдаем, например, у коллег из Debian, это будущее хорошо бы приблизить. Есть предложения? Rgrds, Алексей
On 16.03.2024 04:47, Grigory Ustinov wrote: > Доброго времени суток! > > Вы главное ЕАЭ (Единый Альтовый Экзамен) не вводите. Честно сказать я > как прочитал, сразу не понял, чего хочет топик-стартер, а спустя пару > дней прочитал ещё раз и снова не понял. Переименовать кандидатов в > джуниоров или что? вместо "топик-стартер" можно использовать Антон или Rider. Я не обижусь. Основная цель - дать спокойно работать над своими пакетами без необходимости делать дополнительное review для тех, кто не хочет или не может идти на следующую стадию. > > Потому что фактических изменений я особо не вижу. Разве что разрешение > кандидатам собирать пакеты со своим ацл. Сейчас, я напомню, такие > пакеты требуют одобрения любого участника тим, как и любые другие. > > Давайте по пунктам: > >> Предлагаю считать кандидата на стадии 4.0 уже вступившим в команду, >> но имеющим некоторые ограничения в правах. А именно: > На 3.5 уже по новым нормам человек уже подписан на devel@, что раньше > считалось признаком прохождения джойн. >> - он может отправлять изменения только к тем пакетам, в ACL которых >> он присутствует; > Не реализовано. >> - он может отправлять новые, приналежащие @nobody или @everybody >> пакеты только после review и approve от прошедших стадию 4.2 >> ментейнеров; > И сейчас может. >> - в ACL новых (или принадлежащих @nobody) пакетов, отправляемых >> таким ментейнером лидером устанавливается тот, кто делал approve; > После джойна менторы будут переназначать пачки пакетов на подопечных. > Нынешний вариант считаю лучше. В нынешнем варианте ответственность за качество пакета (лидерство) несёт кандидат. В предлагаемом за качество пакета будет отвечать ментор, который выдал approve. >> - может присутствовать в ACL только в качестве соучастника (не может >> быть лидером и не может оставаться один); > Пустая формальность. А эта формальность нужна для того, что бы кандидат не мог стать лидером пакета и нести ответственность до вступления в тим. >> - не имеет права до окончания процедуры вступления становиться >> ментором новым кандидатам; > И сейчас не имеет. Ни ментором, ни рецензентом. Верно.. > > Хотя я слышал о ситуациях, когда в одном городе менторами становились > люди, прошедшие джойн год назад или может даже меньше. Я точно сказать > не могу, но меня тогда это потрясло, когда я только видел как человек > еле закончил джойн и вот он уже учит кого-то следующего. Лучше бы > поточнее сформулировать список предъявляемых к менторам и рецензентам > требований. Да, согласен. Но это тоже сегментация команды на уровни, хотя мне больше нравится термин роли. > > То есть прозвучало словосочетание "доверенных рецензентов, реально > качественно проверяющих кандидатов", а чьё доверие они должны получать > и каким способом - не понятно. Возможно, что определившись с этим > понятием, мы могли бы получить больше рецензентов. Сейчас им должен доверять секретарь, т.к. по текущему регламенту именно он назначает рецензента. Вообще роль, правила и права рецензента не очень хорошо регламентированы - с одной стороны он должен просто проверить качество работы ментора, но с другой стороны менторы зачастую сваливают на рецензента работу по доведению кандидата до нормального состояния. И это всё, конечно, из-за отсутствия формальных требований к знаниям кандидатов. Я помню, что было так, что после сборки трёх _однотипных_ python пакетов ментор считал кандидата готовым к _самостоятельной_ полноценной работе в Team, что естественно никак не соответствует тому, с чем в реальности придётся столкнуться ментейнеру при работе над пакетной базой Sisyphus. > > Раз уж всё равно затронул тему, то неплохо было бы и определиться с > понятием "качественно проверяющих". В частности требовать от > кандидатов собрать что-то с shared libs, если он планирует заниматься > питоном или собрать питон, если он собирается заниматься чем-то ещё - > это странно. Я не говорю, что это плохо, знания лишними не бывают, но > как минимум обоснование этому можно было бы где-нибудь прописать. > Дескать каждый кандидат должен уметь то то и это. Конечно, и одна из задач, которую должна решить предлагаемая схема - это сделать так, что бы кандидат мог отвечать только за часть репозитория, в которой он силён. > >> - не имеет права голоса в принятии технических решений (но >> естественно может принимать участие в обсуждениях); > И сейчас не имеет, но может обсуждать. > А у нас сейчас нет вообще формального голосования. Этот пункт, скорее, написан на будущее.
On 15.03.2024 21:42, Evgeny Sinelnikov wrote: > Добрый вечер, > > в целом, у предложенного сценария вступления в Team есть положительные > цели, но сам подход откровенно напоминает сегрегацию мейнтейнеров по > не вполне сформулированным, субъективным критериям. > > Прежде всего, тут стоит отметить следующие противоречивые моменты с > точки зрения оценки кандидатов: > * техническая компетенция vs технические предпочтения отдельного члена > Team, который на последнем этапе играет роль рецензента; > * техническое доверие vs техническая предвзятость относительно > принимаемых претендентом технических решений. > > Например, рассмотрим обновление пакета и смену схемы сборки. > > С одной стороны у многих пакетов исторически сложился свой сценарий > сборки, с другой - этот сценарий может казаться не вполне удачным или > технически несовершенным. Как нужно поступать начинающему мейнтейнеру, > если он берётся обновлять такой пакет? Исправлять то, с чем, в свое > время кто-то не справился, или делать по аналогии с уже сложившимся > сценарием сборки? А, если исправлять, то как? Почему так, а не эдак, > если оба варианта равнозначны? > > Тут ведь возникает вилка. Если этот пакет активно сопровождается, то > текущий участник ALT Linux Team, как бы, вправе и к нему нет никакий > претензний. А если пакет заброшен и его предлагается обновить, то у > рецензента возникает возможность предъявить к претенденту на такое > обновление совершенно другие требования. > > Ещё один момент - это соответствие во многом "неписанных" требований, > которые могут быть предъявлены претенденту (кандидату в ALT Linux > Team), тем компетенциям, которым соответствуют или не соответствуют > уже существующие, активные члены команды (собственно, уже прошедшие в > ALT). > > Во избежание двойного толкования требований предлагаю с первых шагов > вступления в Team предъявлять только такие требования и рекомендации, > которые закреплены в соответствующих документах: > - https://www.altlinux.org/Категория:Нормативные_документы > > Такие же требования, которые ещё не закреплены в соответствующих > документах, как минимум, сразу оформлять в качестве Черновиков: > - https://www.altlinux.org/Категория:Черновики_нормативных_документов Отличный план. Но у нас нет работающей хорошей схемы принятия Policy и начать, наверное, надо с этого. Проблема в том, что большинство политик по сборке пакета или не написано или находятся в устаревшем состоянии. Часто сопровождающим просто некогда писать политики (я про себя) и пытаться ещё провести их через регламент согласования. > > Рассчитываю, что новичкам это даст понять, что им есть что опереться в > отстаивании своих технических решений. А также даст нам самим > возможность отделить сложившиеся за годы предпочтения от требований, > которым мы все вместе следуем, даже если они ещё не реализованы. Да, конечно надо приводить в порядок инструкции и политики. Но моё предложение заключалось не в этом. > ____________________________ > > Относительно фиксации вступления в команду на стадии 4.0 есть ещё > одна, уже не техническая тонкость. Утверждение "считать кандидата на > стадии 4.0 уже вступившим в команду" звучит, мягко говоря, достаточно > двусмысленно. Футболку ALT Linux Team тоже будем выдавать с припиской > "Стажёр" или "Junior"? Без приписки. Более того - у нас есть некоторое количество участников команды, которые не собирают пакеты всех возможных типов, не умеют и не должны этого делать. С ними тоже надо что-то придумать, и предлагаемая схема решает ещё и эту задачу. Пример - переводчики, разработчики документации, тестировщики и дизайнеры. > > На самом деле тут стоит ведь исходить скорее из интереса и мотивации > вступающих в Team: > - Участие в развитии проекта Sisyphus; > - Сопровождение конкретных пакетов для бизнеса (например, от лица той > или иной заинтересованной компании, в том числе и Базальт СПО); > - ... ? > > Если речь идёт о втором варианте, то я не вижу никаких препятствий для > введения промежуточной стадии, когда человек сам понимает, что участие > в ALT Linux Team для него, всего лишь рабочий момент. Но если речь > идёт о первом варианте, то совершенно не стоит предлагать ему > оскорбительную полумеру. Она совершенно никого не оскорбляет. Я знаю кандидатов, которые вступают в тим ради сборки одного пакета. Вероятно им вообще никогда не понадобиться уметь собирать пакеты, например, написанные на python. > > В любом случае, критерии оценки технической компетенции нужно > развивать для того, чтобы сохранять честность и убедительность. Как > для кандидатов, так и для действующих членов ALT Linux Team. Я только за - www.altlinux.org открыт для редактирования всеми, кто хочет принять в этом участие. Или ты предлагаешь взвалить эту задачу на меня, как на инициатора данного треда ?
Согласен. Примерно тоже-самое написал в bugzilla - непонятно какую цель
хочется достичь.
On 15.03.2024 19:08, Evgeny Sinelnikov wrote:
> Добрый вечер,
>
> поскольку суть обсуждения явно не заявлена, попытаюсь её сформулировать.
>
> Речь идёт о файлах интроспекции. Стоит или не стоит их хранить вместе
> с пакетами? Или может быть стоит выносить в отдельные подпакеты?
>
> На мой взгляд это совершенно бесполезно, особенно в тех случаях, когда
> клиентам нужно проверять валидность интерфейсов. Например, мы именно
> для этого его сейчас используем для всех новых бекендов, создаваемых с
> помощью модуля alterator-module-executor.
>
> Кроме того, существует, действительно, и такая штука, как
> "кодогенерация на лету". Хотя "кодогенерацией" это может и не
> являться. Скорее статическим способом интроспекции.
>
> Стоит упомянуть также и такую особенность, как сам интерфейс
> интроспекции. Устроен он так, что выдаёт ровно те же xml'ки, которые
> предлагается куда-то, зачем-то спрятать:
>
> $ busctl call org.freedesktop.Accounts /org/freedesktop/Accounts
> org.freedesktop.DBus.Introspectable Introspect
> s "<!DOCTYPE node PUBLIC \"-//freedesktop//DTD D-BUS Object
> Introspection 1.0//EN\"\n
> [...]
> </interface>\n <node name=\"User758801104\"/>\n <node
> name=\"User500\"/>\n</node>\n"
>
> Ну, то есть все приложения и так выдают свой интерфейс в этом же
> формате. В ряде случаев, я думаю, это даже может быть реализовано как
> отправка в ответ на org.freedesktop.DBus.Introspectable.Introspect()
> содержимое того файла, который лежит в каталоге
> /usr/share/dbus-1/interfaces/, вместо того, чтобы прибивать его
> "гвоздями" в код сервиса.
>
> В общем, не понятна цель ради которой что-то предлагается. Свести dbus
> интроспекцию только к кодогенерации уже не очень получится. Разве что
> перенести эти файлы в отдельные пакеты может иметь смысл, чтобы не
> тащить в сборочное окружение лишние пакеты с их зависимостями. Тогда
> цель становится понятной. Но это довольно тогда большая работа. У нас
> и без неё много всего лишнего тянется в сборочное окружение. Эту
> задачу нужно решать более комплексно, я думаю. Уж точно не с dbusxml
> файлов начинать стоит.
>
>
> пт, 15 мар. 2024 г. в 17:21, Sergey V Turchin <zerg@altlinux.org>:
>> Привет всем!
>>
>> Предлагаю обсудить https://bugs.altlinux.org/49665 .
>> https://dbus.freedesktop.org/doc/dbus-api-design.html#code-generation
>> https://dbus.freedesktop.org/doc/dbus-api-design.html#apis
>> https://dbus.freedesktop.org/doc/dbus-specification.html#introspection-format
>>
>> --
>> Regards, Sergey.
>> _______________________________________________
>> Devel mailing list
>> Devel@lists.altlinux.org
>> https://lists.altlinux.org/mailman/listinfo/devel
>
>
Доброго времени суток! Вы главное ЕАЭ (Единый Альтовый Экзамен) не вводите. Честно сказать я как прочитал, сразу не понял, чего хочет топик-стартер, а спустя пару дней прочитал ещё раз и снова не понял. Переименовать кандидатов в джуниоров или что? Потому что фактических изменений я особо не вижу. Разве что разрешение кандидатам собирать пакеты со своим ацл. Сейчас, я напомню, такие пакеты требуют одобрения любого участника тим, как и любые другие. Давайте по пунктам: > Предлагаю считать кандидата на стадии 4.0 уже вступившим в команду, но > имеющим некоторые ограничения в правах. А именно: На 3.5 уже по новым нормам человек уже подписан на devel@, что раньше считалось признаком прохождения джойн. > - он может отправлять изменения только к тем пакетам, в ACL которых он > присутствует; Не реализовано. > - он может отправлять новые, приналежащие @nobody или @everybody > пакеты только после review и approve от прошедших стадию 4.2 ментейнеров; И сейчас может. > - в ACL новых (или принадлежащих @nobody) пакетов, отправляемых таким > ментейнером лидером устанавливается тот, кто делал approve; После джойна менторы будут переназначать пачки пакетов на подопечных. Нынешний вариант считаю лучше. > - может присутствовать в ACL только в качестве соучастника (не может > быть лидером и не может оставаться один); Пустая формальность. > - не имеет права до окончания процедуры вступления становиться > ментором новым кандидатам; И сейчас не имеет. Ни ментором, ни рецензентом. Хотя я слышал о ситуациях, когда в одном городе менторами становились люди, прошедшие джойн год назад или может даже меньше. Я точно сказать не могу, но меня тогда это потрясло, когда я только видел как человек еле закончил джойн и вот он уже учит кого-то следующего. Лучше бы поточнее сформулировать список предъявляемых к менторам и рецензентам требований. То есть прозвучало словосочетание "доверенных рецензентов, реально качественно проверяющих кандидатов", а чьё доверие они должны получать и каким способом - не понятно. Возможно, что определившись с этим понятием, мы могли бы получить больше рецензентов. Раз уж всё равно затронул тему, то неплохо было бы и определиться с понятием "качественно проверяющих". В частности требовать от кандидатов собрать что-то с shared libs, если он планирует заниматься питоном или собрать питон, если он собирается заниматься чем-то ещё - это странно. Я не говорю, что это плохо, знания лишними не бывают, но как минимум обоснование этому можно было бы где-нибудь прописать. Дескать каждый кандидат должен уметь то то и это. > - не имеет права голоса в принятии технических решений (но естественно > может принимать участие в обсуждениях); И сейчас не имеет, но может обсуждать. --- Подведу черту. Желание топик-стартера формализовать некоторые моменты в джойне в общем понятно, но это всё очень сильно напоминает законодательство. И тут главный вопрос: а в чьих интересах предложенные изменения? Когда меня подопечные спрашивают "когда конец джойна?", я обычно отвечаю что-то вроде "когда я посчитаю, что вы достаточно освоили базовые знания и навыки". Да, возникает неравенство. Кто-то проходит джойн быстрее, кто-то дольше. Кто-то лучше, кто-то хуже. Я считаю, что люди индивидуальны и требуют индивидуального подхода. Кому-то достаточно несколько пакетов собрать, кому-то и полтора десятка будет мало. Поэтому формализуй не формализуй регламент джойна, этот опыт для каждого участника будет свой. Повторюсь: вы главное аналог ЕГЭ не вводите. Спасибо за внимание! P.S. На всякий случай.. Никого из соседнего города обижать или задевать не хотел. 15.03.2024 21:42, Evgeny Sinelnikov пишет: > Добрый вечер, > > в целом, у предложенного сценария вступления в Team есть положительные > цели, но сам подход откровенно напоминает сегрегацию мейнтейнеров по > не вполне сформулированным, субъективным критериям. > > Прежде всего, тут стоит отметить следующие противоречивые моменты с > точки зрения оценки кандидатов: > * техническая компетенция vs технические предпочтения отдельного члена > Team, который на последнем этапе играет роль рецензента; > * техническое доверие vs техническая предвзятость относительно > принимаемых претендентом технических решений. > > Например, рассмотрим обновление пакета и смену схемы сборки. > > С одной стороны у многих пакетов исторически сложился свой сценарий > сборки, с другой - этот сценарий может казаться не вполне удачным или > технически несовершенным. Как нужно поступать начинающему мейнтейнеру, > если он берётся обновлять такой пакет? Исправлять то, с чем, в свое > время кто-то не справился, или делать по аналогии с уже сложившимся > сценарием сборки? А, если исправлять, то как? Почему так, а не эдак, > если оба варианта равнозначны? > > Тут ведь возникает вилка. Если этот пакет активно сопровождается, то > текущий участник ALT Linux Team, как бы, вправе и к нему нет никакий > претензний. А если пакет заброшен и его предлагается обновить, то у > рецензента возникает возможность предъявить к претенденту на такое > обновление совершенно другие требования. > > Ещё один момент - это соответствие во многом "неписанных" требований, > которые могут быть предъявлены претенденту (кандидату в ALT Linux > Team), тем компетенциям, которым соответствуют или не соответствуют > уже существующие, активные члены команды (собственно, уже прошедшие в > ALT). > > Во избежание двойного толкования требований предлагаю с первых шагов > вступления в Team предъявлять только такие требования и рекомендации, > которые закреплены в соответствующих документах: > - https://www.altlinux.org/Категория:Нормативные_документы > > Такие же требования, которые ещё не закреплены в соответствующих > документах, как минимум, сразу оформлять в качестве Черновиков: > - https://www.altlinux.org/Категория:Черновики_нормативных_документов > > Рассчитываю, что новичкам это даст понять, что им есть что опереться в > отстаивании своих технических решений. А также даст нам самим > возможность отделить сложившиеся за годы предпочтения от требований, > которым мы все вместе следуем, даже если они ещё не реализованы. > ____________________________ > > Относительно фиксации вступления в команду на стадии 4.0 есть ещё > одна, уже не техническая тонкость. Утверждение "считать кандидата на > стадии 4.0 уже вступившим в команду" звучит, мягко говоря, достаточно > двусмысленно. Футболку ALT Linux Team тоже будем выдавать с припиской > "Стажёр" или "Junior"? > > На самом деле тут стоит ведь исходить скорее из интереса и мотивации > вступающих в Team: > - Участие в развитии проекта Sisyphus; > - Сопровождение конкретных пакетов для бизнеса (например, от лица той > или иной заинтересованной компании, в том числе и Базальт СПО); > - ... ? > > Если речь идёт о втором варианте, то я не вижу никаких препятствий для > введения промежуточной стадии, когда человек сам понимает, что участие > в ALT Linux Team для него, всего лишь рабочий момент. Но если речь > идёт о первом варианте, то совершенно не стоит предлагать ему > оскорбительную полумеру. > > В любом случае, критерии оценки технической компетенции нужно > развивать для того, чтобы сохранять честность и убедительность. Как > для кандидатов, так и для действующих членов ALT Linux Team. > > > > пт, 15 мар. 2024 г. в 17:16, Danil Shein <dshein@basealt.ru>: >> Добрый день! >> >> Относительно наименования нового участника ALT Linux Team на этапе 4.0: >> >> Выбор конкретного наименования, как мне кажется, не принципиален. >> Использование названия "junior maintainer" сильно лучше русскоязычных >> вариантов. >> >> Мне схема с использованием ACL в целом кажется вполне разумной, а >> главное технически реализуемой. >> >> Относительно документального сопровождения процесса JOIN: >> >> Мне лично, чтобы вспомнить что такое этап "4.0", потребовалось таки >> искать описание процедуры на вики. >> Более того, вступающему найти эту информацию сходу тоже не так-то просто >> ибо она расположена в статье про обязанности "секретаря" команды - нужно >> ещё догадаться где искать или спрашивать у ментора. >> >> Отсюда пара моментов для обсуждения: >> >> - Возможно имеет смысл дать какие-то говорящие названия этапам JOIN (да >> хоть отрицание/гнев/торг/депрессия/принятие - как раз 5 этапов)? >> >> Например: >> * 1.0 - Заявка >> * 2.0 - Регистрация >> * 3.0 - Подтверждение >> * 4.0 - Аттестация (Квалификация, Экзамен etc.) >> * 5.0 - Вступление >> >> - Обновить или добавить на вики описание процедуры JOIN в более понятном >> виде? >> >> 14.03.2024 21:16, Anton Farygin пишет: >>> Всем привет. >>> >>> Как многим из вас известно, у нас довольно тяжёлый для прохождения >>> регламент JOIN в ALT Linux Team, включающей в себя дополнительного >>> рецензента работы ментора. >>> >>> Решение о появлении этапа контролёра понятно и было продиктовано >>> реальными случаями попадания в Team людей, не обладающих всем спектром >>> знаний для полноценной и качественной самостоятельной работой над >>> достаточно сложной и разнообразной пакетной базой репозитория. >>> >>> И в целом такое решение могло бы нормально работать, но у нас >>> появилось узкое место из-за отсутствия доверенных рецензентов, реально >>> качественно проверяющих кандидатов и при этом уделяющих процессу >>> взаимодействия с кандидатом достаточно много времени. >>> >>> Из опыта эксплуатации действующего сейчас регламента JOIN могу сказать >>> что вступление в команду для полноценной самостоятельной работы из-за >>> отсутствия рецензента или их оперативности стало затягиваться уже не >>> на месяцы а на годы. >>> >>> Считаю это плохим фактором для дальнейшего роста нашей дружной команды >>> и хочу предложить сообществу к рассмотрению точечные изменения к этой >>> схеме. >>> >>> Изменения будут заключаться в формальном статусе кандидата на стадии >>> ожидания рецензента. >>> >>> Предлагаю считать кандидата на стадии 4.0 уже вступившим в команду, но >>> имеющим некоторые ограничения в правах. А именно: >>> >>> - он может отправлять изменения только к тем пакетам, в ACL которых он >>> присутствует; >>> >>> - он может отправлять новые, приналежащие @nobody или @everybody >>> пакеты только после review и approve от прошедших стадию 4.2 ментейнеров; >>> >>> - в ACL новых (или принадлежащих @nobody) пакетов, отправляемых таким >>> ментейнером лидером устанавливается тот, кто делал approve; >>> >>> - может присутствовать в ACL только в качестве соучастника (не может >>> быть лидером и не может оставаться один); >>> >>> - не имеет права до окончания процедуры вступления становиться >>> ментором новым кандидатам; >>> >>> - не имеет права голоса в принятии технических решений (но естественно >>> может принимать участие в обсуждениях); >>> >>> >>> при этом ментор фактически завершает свою работу и в дальнейшем росте >>> такого ментейнера в команде становятся все участники. >>> >>> Для данной стадии предлагается выбрать соответствующее название и я >>> придумал несколько вариантов, которые предлагаю заодно обсудить в >>> данном треде: >>> >>> 1) Стажёр >>> >>> 2) Практикант >>> >>> 3) Подмастерье >>> >>> 4) Ученик >>> >>> 5) Junior (термин, привычный в IT области) >>> >>> >>> Мне лично из всех вариантов названия предлагаемой стадии нравится >>> больше junior maintainer, но возможно у кого-то будут и другие, более >>> интересные варианты. >>> >>> >>> Процесс перехода от стадии 4.0 на стадию 5.0 надо продумать, как >>> вариант можно рассмотреть решение по запросу секретаря на такой >>> переход от одного или нескольких из тех самых "доверенных" >>> ментейнеров, кому обычно секретарь JOIN поручает рецензирование. >>> >>> Но т.к. после предлагаемых изменений кандидат на стадии 4.0 становится >>> фактически полноценным участником Team, может собирать пакеты, >>> взаимодействовать по разным компонентам системы с другими участниками >>> команды, принимать участие в обсуждении и выработке технологических >>> решений - то острота завершения JOIN резко падает и секретарю, >>> рецензенту и самому кандидату становиться намного проще. >>> >>> Предлагаю обсудить этот вопрос и по результатом обсуждения я >>> подготовлю и пришлю в рассылку консолидированные предложения для >>> изменения существующего регламента. >>> >>> >>> Антон >>> >>> >>> _______________________________________________ >>> Devel mailing list >>> Devel@lists.altlinux.org >>> https://lists.altlinux.org/mailman/listinfo/devel >> -- >> >> *Данил Шеин / Danil Shein* >> >> dshein@altlinux.org >> dshein@basealt.ru >> >> _______________________________________________ >> Devel mailing list >> Devel@lists.altlinux.org >> https://lists.altlinux.org/mailman/listinfo/devel > >
Добрый вечер, в целом, у предложенного сценария вступления в Team есть положительные цели, но сам подход откровенно напоминает сегрегацию мейнтейнеров по не вполне сформулированным, субъективным критериям. Прежде всего, тут стоит отметить следующие противоречивые моменты с точки зрения оценки кандидатов: * техническая компетенция vs технические предпочтения отдельного члена Team, который на последнем этапе играет роль рецензента; * техническое доверие vs техническая предвзятость относительно принимаемых претендентом технических решений. Например, рассмотрим обновление пакета и смену схемы сборки. С одной стороны у многих пакетов исторически сложился свой сценарий сборки, с другой - этот сценарий может казаться не вполне удачным или технически несовершенным. Как нужно поступать начинающему мейнтейнеру, если он берётся обновлять такой пакет? Исправлять то, с чем, в свое время кто-то не справился, или делать по аналогии с уже сложившимся сценарием сборки? А, если исправлять, то как? Почему так, а не эдак, если оба варианта равнозначны? Тут ведь возникает вилка. Если этот пакет активно сопровождается, то текущий участник ALT Linux Team, как бы, вправе и к нему нет никакий претензний. А если пакет заброшен и его предлагается обновить, то у рецензента возникает возможность предъявить к претенденту на такое обновление совершенно другие требования. Ещё один момент - это соответствие во многом "неписанных" требований, которые могут быть предъявлены претенденту (кандидату в ALT Linux Team), тем компетенциям, которым соответствуют или не соответствуют уже существующие, активные члены команды (собственно, уже прошедшие в ALT). Во избежание двойного толкования требований предлагаю с первых шагов вступления в Team предъявлять только такие требования и рекомендации, которые закреплены в соответствующих документах: - https://www.altlinux.org/Категория:Нормативные_документы Такие же требования, которые ещё не закреплены в соответствующих документах, как минимум, сразу оформлять в качестве Черновиков: - https://www.altlinux.org/Категория:Черновики_нормативных_документов Рассчитываю, что новичкам это даст понять, что им есть что опереться в отстаивании своих технических решений. А также даст нам самим возможность отделить сложившиеся за годы предпочтения от требований, которым мы все вместе следуем, даже если они ещё не реализованы. ____________________________ Относительно фиксации вступления в команду на стадии 4.0 есть ещё одна, уже не техническая тонкость. Утверждение "считать кандидата на стадии 4.0 уже вступившим в команду" звучит, мягко говоря, достаточно двусмысленно. Футболку ALT Linux Team тоже будем выдавать с припиской "Стажёр" или "Junior"? На самом деле тут стоит ведь исходить скорее из интереса и мотивации вступающих в Team: - Участие в развитии проекта Sisyphus; - Сопровождение конкретных пакетов для бизнеса (например, от лица той или иной заинтересованной компании, в том числе и Базальт СПО); - ... ? Если речь идёт о втором варианте, то я не вижу никаких препятствий для введения промежуточной стадии, когда человек сам понимает, что участие в ALT Linux Team для него, всего лишь рабочий момент. Но если речь идёт о первом варианте, то совершенно не стоит предлагать ему оскорбительную полумеру. В любом случае, критерии оценки технической компетенции нужно развивать для того, чтобы сохранять честность и убедительность. Как для кандидатов, так и для действующих членов ALT Linux Team. пт, 15 мар. 2024 г. в 17:16, Danil Shein <dshein@basealt.ru>: > > Добрый день! > > Относительно наименования нового участника ALT Linux Team на этапе 4.0: > > Выбор конкретного наименования, как мне кажется, не принципиален. > Использование названия "junior maintainer" сильно лучше русскоязычных > вариантов. > > Мне схема с использованием ACL в целом кажется вполне разумной, а > главное технически реализуемой. > > Относительно документального сопровождения процесса JOIN: > > Мне лично, чтобы вспомнить что такое этап "4.0", потребовалось таки > искать описание процедуры на вики. > Более того, вступающему найти эту информацию сходу тоже не так-то просто > ибо она расположена в статье про обязанности "секретаря" команды - нужно > ещё догадаться где искать или спрашивать у ментора. > > Отсюда пара моментов для обсуждения: > > - Возможно имеет смысл дать какие-то говорящие названия этапам JOIN (да > хоть отрицание/гнев/торг/депрессия/принятие - как раз 5 этапов)? > > Например: > * 1.0 - Заявка > * 2.0 - Регистрация > * 3.0 - Подтверждение > * 4.0 - Аттестация (Квалификация, Экзамен etc.) > * 5.0 - Вступление > > - Обновить или добавить на вики описание процедуры JOIN в более понятном > виде? > > 14.03.2024 21:16, Anton Farygin пишет: > > Всем привет. > > > > Как многим из вас известно, у нас довольно тяжёлый для прохождения > > регламент JOIN в ALT Linux Team, включающей в себя дополнительного > > рецензента работы ментора. > > > > Решение о появлении этапа контролёра понятно и было продиктовано > > реальными случаями попадания в Team людей, не обладающих всем спектром > > знаний для полноценной и качественной самостоятельной работой над > > достаточно сложной и разнообразной пакетной базой репозитория. > > > > И в целом такое решение могло бы нормально работать, но у нас > > появилось узкое место из-за отсутствия доверенных рецензентов, реально > > качественно проверяющих кандидатов и при этом уделяющих процессу > > взаимодействия с кандидатом достаточно много времени. > > > > Из опыта эксплуатации действующего сейчас регламента JOIN могу сказать > > что вступление в команду для полноценной самостоятельной работы из-за > > отсутствия рецензента или их оперативности стало затягиваться уже не > > на месяцы а на годы. > > > > Считаю это плохим фактором для дальнейшего роста нашей дружной команды > > и хочу предложить сообществу к рассмотрению точечные изменения к этой > > схеме. > > > > Изменения будут заключаться в формальном статусе кандидата на стадии > > ожидания рецензента. > > > > Предлагаю считать кандидата на стадии 4.0 уже вступившим в команду, но > > имеющим некоторые ограничения в правах. А именно: > > > > - он может отправлять изменения только к тем пакетам, в ACL которых он > > присутствует; > > > > - он может отправлять новые, приналежащие @nobody или @everybody > > пакеты только после review и approve от прошедших стадию 4.2 ментейнеров; > > > > - в ACL новых (или принадлежащих @nobody) пакетов, отправляемых таким > > ментейнером лидером устанавливается тот, кто делал approve; > > > > - может присутствовать в ACL только в качестве соучастника (не может > > быть лидером и не может оставаться один); > > > > - не имеет права до окончания процедуры вступления становиться > > ментором новым кандидатам; > > > > - не имеет права голоса в принятии технических решений (но естественно > > может принимать участие в обсуждениях); > > > > > > при этом ментор фактически завершает свою работу и в дальнейшем росте > > такого ментейнера в команде становятся все участники. > > > > Для данной стадии предлагается выбрать соответствующее название и я > > придумал несколько вариантов, которые предлагаю заодно обсудить в > > данном треде: > > > > 1) Стажёр > > > > 2) Практикант > > > > 3) Подмастерье > > > > 4) Ученик > > > > 5) Junior (термин, привычный в IT области) > > > > > > Мне лично из всех вариантов названия предлагаемой стадии нравится > > больше junior maintainer, но возможно у кого-то будут и другие, более > > интересные варианты. > > > > > > Процесс перехода от стадии 4.0 на стадию 5.0 надо продумать, как > > вариант можно рассмотреть решение по запросу секретаря на такой > > переход от одного или нескольких из тех самых "доверенных" > > ментейнеров, кому обычно секретарь JOIN поручает рецензирование. > > > > Но т.к. после предлагаемых изменений кандидат на стадии 4.0 становится > > фактически полноценным участником Team, может собирать пакеты, > > взаимодействовать по разным компонентам системы с другими участниками > > команды, принимать участие в обсуждении и выработке технологических > > решений - то острота завершения JOIN резко падает и секретарю, > > рецензенту и самому кандидату становиться намного проще. > > > > Предлагаю обсудить этот вопрос и по результатом обсуждения я > > подготовлю и пришлю в рассылку консолидированные предложения для > > изменения существующего регламента. > > > > > > Антон > > > > > > _______________________________________________ > > Devel mailing list > > Devel@lists.altlinux.org > > https://lists.altlinux.org/mailman/listinfo/devel > -- > > *Данил Шеин / Danil Shein* > > dshein@altlinux.org > dshein@basealt.ru > > _______________________________________________ > Devel mailing list > Devel@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/devel -- Sin (Sinelnikov Evgeny)
Добрый вечер,
поскольку суть обсуждения явно не заявлена, попытаюсь её сформулировать.
Речь идёт о файлах интроспекции. Стоит или не стоит их хранить вместе
с пакетами? Или может быть стоит выносить в отдельные подпакеты?
На мой взгляд это совершенно бесполезно, особенно в тех случаях, когда
клиентам нужно проверять валидность интерфейсов. Например, мы именно
для этого его сейчас используем для всех новых бекендов, создаваемых с
помощью модуля alterator-module-executor.
Кроме того, существует, действительно, и такая штука, как
"кодогенерация на лету". Хотя "кодогенерацией" это может и не
являться. Скорее статическим способом интроспекции.
Стоит упомянуть также и такую особенность, как сам интерфейс
интроспекции. Устроен он так, что выдаёт ровно те же xml'ки, которые
предлагается куда-то, зачем-то спрятать:
$ busctl call org.freedesktop.Accounts /org/freedesktop/Accounts
org.freedesktop.DBus.Introspectable Introspect
s "<!DOCTYPE node PUBLIC \"-//freedesktop//DTD D-BUS Object
Introspection 1.0//EN\"\n
[...]
</interface>\n <node name=\"User758801104\"/>\n <node
name=\"User500\"/>\n</node>\n"
Ну, то есть все приложения и так выдают свой интерфейс в этом же
формате. В ряде случаев, я думаю, это даже может быть реализовано как
отправка в ответ на org.freedesktop.DBus.Introspectable.Introspect()
содержимое того файла, который лежит в каталоге
/usr/share/dbus-1/interfaces/, вместо того, чтобы прибивать его
"гвоздями" в код сервиса.
В общем, не понятна цель ради которой что-то предлагается. Свести dbus
интроспекцию только к кодогенерации уже не очень получится. Разве что
перенести эти файлы в отдельные пакеты может иметь смысл, чтобы не
тащить в сборочное окружение лишние пакеты с их зависимостями. Тогда
цель становится понятной. Но это довольно тогда большая работа. У нас
и без неё много всего лишнего тянется в сборочное окружение. Эту
задачу нужно решать более комплексно, я думаю. Уж точно не с dbusxml
файлов начинать стоит.
пт, 15 мар. 2024 г. в 17:21, Sergey V Turchin <zerg@altlinux.org>:
>
> Привет всем!
>
> Предлагаю обсудить https://bugs.altlinux.org/49665 .
> https://dbus.freedesktop.org/doc/dbus-api-design.html#code-generation
> https://dbus.freedesktop.org/doc/dbus-api-design.html#apis
> https://dbus.freedesktop.org/doc/dbus-specification.html#introspection-format
>
> --
> Regards, Sergey.
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
--
Sin (Sinelnikov Evgeny)
Добрый день!
Относительно наименования нового участника ALT Linux Team на этапе 4.0:
Выбор конкретного наименования, как мне кажется, не принципиален.
Использование названия "junior maintainer" сильно лучше русскоязычных
вариантов.
Мне схема с использованием ACL в целом кажется вполне разумной, а
главное технически реализуемой.
Относительно документального сопровождения процесса JOIN:
Мне лично, чтобы вспомнить что такое этап "4.0", потребовалось таки
искать описание процедуры на вики.
Более того, вступающему найти эту информацию сходу тоже не так-то просто
ибо она расположена в статье про обязанности "секретаря" команды - нужно
ещё догадаться где искать или спрашивать у ментора.
Отсюда пара моментов для обсуждения:
- Возможно имеет смысл дать какие-то говорящие названия этапам JOIN (да
хоть отрицание/гнев/торг/депрессия/принятие - как раз 5 этапов)?
Например:
* 1.0 - Заявка
* 2.0 - Регистрация
* 3.0 - Подтверждение
* 4.0 - Аттестация (Квалификация, Экзамен etc.)
* 5.0 - Вступление
- Обновить или добавить на вики описание процедуры JOIN в более понятном
виде?
14.03.2024 21:16, Anton Farygin пишет:
> Всем привет.
>
> Как многим из вас известно, у нас довольно тяжёлый для прохождения
> регламент JOIN в ALT Linux Team, включающей в себя дополнительного
> рецензента работы ментора.
>
> Решение о появлении этапа контролёра понятно и было продиктовано
> реальными случаями попадания в Team людей, не обладающих всем спектром
> знаний для полноценной и качественной самостоятельной работой над
> достаточно сложной и разнообразной пакетной базой репозитория.
>
> И в целом такое решение могло бы нормально работать, но у нас
> появилось узкое место из-за отсутствия доверенных рецензентов, реально
> качественно проверяющих кандидатов и при этом уделяющих процессу
> взаимодействия с кандидатом достаточно много времени.
>
> Из опыта эксплуатации действующего сейчас регламента JOIN могу сказать
> что вступление в команду для полноценной самостоятельной работы из-за
> отсутствия рецензента или их оперативности стало затягиваться уже не
> на месяцы а на годы.
>
> Считаю это плохим фактором для дальнейшего роста нашей дружной команды
> и хочу предложить сообществу к рассмотрению точечные изменения к этой
> схеме.
>
> Изменения будут заключаться в формальном статусе кандидата на стадии
> ожидания рецензента.
>
> Предлагаю считать кандидата на стадии 4.0 уже вступившим в команду, но
> имеющим некоторые ограничения в правах. А именно:
>
> - он может отправлять изменения только к тем пакетам, в ACL которых он
> присутствует;
>
> - он может отправлять новые, приналежащие @nobody или @everybody
> пакеты только после review и approve от прошедших стадию 4.2 ментейнеров;
>
> - в ACL новых (или принадлежащих @nobody) пакетов, отправляемых таким
> ментейнером лидером устанавливается тот, кто делал approve;
>
> - может присутствовать в ACL только в качестве соучастника (не может
> быть лидером и не может оставаться один);
>
> - не имеет права до окончания процедуры вступления становиться
> ментором новым кандидатам;
>
> - не имеет права голоса в принятии технических решений (но естественно
> может принимать участие в обсуждениях);
>
>
> при этом ментор фактически завершает свою работу и в дальнейшем росте
> такого ментейнера в команде становятся все участники.
>
> Для данной стадии предлагается выбрать соответствующее название и я
> придумал несколько вариантов, которые предлагаю заодно обсудить в
> данном треде:
>
> 1) Стажёр
>
> 2) Практикант
>
> 3) Подмастерье
>
> 4) Ученик
>
> 5) Junior (термин, привычный в IT области)
>
>
> Мне лично из всех вариантов названия предлагаемой стадии нравится
> больше junior maintainer, но возможно у кого-то будут и другие, более
> интересные варианты.
>
>
> Процесс перехода от стадии 4.0 на стадию 5.0 надо продумать, как
> вариант можно рассмотреть решение по запросу секретаря на такой
> переход от одного или нескольких из тех самых "доверенных"
> ментейнеров, кому обычно секретарь JOIN поручает рецензирование.
>
> Но т.к. после предлагаемых изменений кандидат на стадии 4.0 становится
> фактически полноценным участником Team, может собирать пакеты,
> взаимодействовать по разным компонентам системы с другими участниками
> команды, принимать участие в обсуждении и выработке технологических
> решений - то острота завершения JOIN резко падает и секретарю,
> рецензенту и самому кандидату становиться намного проще.
>
> Предлагаю обсудить этот вопрос и по результатом обсуждения я
> подготовлю и пришлю в рассылку консолидированные предложения для
> изменения существующего регламента.
>
>
> Антон
>
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
--
*Данил Шеин / Danil Shein*
dshein@altlinux.org
dshein@basealt.ru
Всем привет. Как многим из вас известно, у нас довольно тяжёлый для прохождения регламент JOIN в ALT Linux Team, включающей в себя дополнительного рецензента работы ментора. Решение о появлении этапа контролёра понятно и было продиктовано реальными случаями попадания в Team людей, не обладающих всем спектром знаний для полноценной и качественной самостоятельной работой над достаточно сложной и разнообразной пакетной базой репозитория. И в целом такое решение могло бы нормально работать, но у нас появилось узкое место из-за отсутствия доверенных рецензентов, реально качественно проверяющих кандидатов и при этом уделяющих процессу взаимодействия с кандидатом достаточно много времени. Из опыта эксплуатации действующего сейчас регламента JOIN могу сказать что вступление в команду для полноценной самостоятельной работы из-за отсутствия рецензента или их оперативности стало затягиваться уже не на месяцы а на годы. Считаю это плохим фактором для дальнейшего роста нашей дружной команды и хочу предложить сообществу к рассмотрению точечные изменения к этой схеме. Изменения будут заключаться в формальном статусе кандидата на стадии ожидания рецензента. Предлагаю считать кандидата на стадии 4.0 уже вступившим в команду, но имеющим некоторые ограничения в правах. А именно: - он может отправлять изменения только к тем пакетам, в ACL которых он присутствует; - он может отправлять новые, приналежащие @nobody или @everybody пакеты только после review и approve от прошедших стадию 4.2 ментейнеров; - в ACL новых (или принадлежащих @nobody) пакетов, отправляемых таким ментейнером лидером устанавливается тот, кто делал approve; - может присутствовать в ACL только в качестве соучастника (не может быть лидером и не может оставаться один); - не имеет права до окончания процедуры вступления становиться ментором новым кандидатам; - не имеет права голоса в принятии технических решений (но естественно может принимать участие в обсуждениях); при этом ментор фактически завершает свою работу и в дальнейшем росте такого ментейнера в команде становятся все участники. Для данной стадии предлагается выбрать соответствующее название и я придумал несколько вариантов, которые предлагаю заодно обсудить в данном треде: 1) Стажёр 2) Практикант 3) Подмастерье 4) Ученик 5) Junior (термин, привычный в IT области) Мне лично из всех вариантов названия предлагаемой стадии нравится больше junior maintainer, но возможно у кого-то будут и другие, более интересные варианты. Процесс перехода от стадии 4.0 на стадию 5.0 надо продумать, как вариант можно рассмотреть решение по запросу секретаря на такой переход от одного или нескольких из тех самых "доверенных" ментейнеров, кому обычно секретарь JOIN поручает рецензирование. Но т.к. после предлагаемых изменений кандидат на стадии 4.0 становится фактически полноценным участником Team, может собирать пакеты, взаимодействовать по разным компонентам системы с другими участниками команды, принимать участие в обсуждении и выработке технологических решений - то острота завершения JOIN резко падает и секретарю, рецензенту и самому кандидату становиться намного проще. Предлагаю обсудить этот вопрос и по результатом обсуждения я подготовлю и пришлю в рассылку консолидированные предложения для изменения существующего регламента. Антон
On 13.03.2024 14:20, Leonid Krivoshein wrote:
>
> On 3/13/24 11:21, Sergei Epiphanov wrote:
>> Как минимум qt3, qt4 со всеми средствами сборки и нужными
>> библиотеками. Да и вообще нужно запускать систему на i586-платформе,
>> которая не знает ничего об x64, но должна работать с нестандартными
>> железками через PCI/COM/USB.
>>
>
> Что мешает использовать для всего перечисленного старые дистрибутивы
> из архивов? Если речь о встраиваемом железе, то новые версии ОС Альт
> на него не ориентированы по объективным причинам. Десктопов таких уже
> не делают, софт для i586 не поддерживают уже многие апстримы. Даже
> ведущий мировой поставщик десктоп систем решил вопрос просто и
> кардинально, хотя речь о совместимости с его же продукцией. Мы не
> можем этого повторить даже спустя столько лет?
пока рано.