[devel] Статус архитектур после бранчевания

Paul Wolneykien manowar на altlinux.org
Чт Ноя 23 12:36:39 MSK 2023


В Thu, 23 Nov 2023 10:51:00 +0300
Anton Farygin <rider на basealt.ru> пишет:

> On 23.11.2023 10:26, Aleksey Novodvorsky wrote:
> > чт, 23 нояб. 2023 г. в 10:20, Anton Farygin<rider на basealt.ru>:  
> >> On 23.11.2023 10:18, Aleksey Novodvorsky wrote:  
> >>>> С powerpc было так-же и до какого-то времени была отличная поддержка
> >>>> ментейнерам со стороны сопровождающей команды. А потом она кончилась.  
> >>> Еще и поэтому мы с ней прощаемся.  
> >> А можно было и не здороваться.  
> > Когда мы принимали это решение, поставки серверов Power  росли.
> > И поддержка архитектуры была во всех международных проектах.  
> 
> Так она и сейчас есть, намного лучше чем e2k или loongarch.
> 
> Но вопрос не в наличии поддержки в апстриме, а в наличии железа у 
> ментейнеров и _желания_ с ним возиться.

  А мы не можем решить этот вопрос как-то аналогично ACL?

  Допустим, мне интересно, чтобы мой пакет собирался на догоняющей
архитектуре follow_archXX. И допустим я хочу принимать в отношении
данного пакета живое участие в сборке его на archXX, а не просто
надеяться на команду портирующих. И для этого я добавляю в ACL
пакета что-то вроде @follow_archXX. После этого сборочные задания
с этим пакетом начинают зеркалиться на догоняющую сборочницу, а мне
начинают приходить письма от неё. Если (когда) мне надоедает заниматься
archXX, я удаляю из ACL @follow_archXX. Письма от догоняющей сборочницы
перестают приходить. А вот что должно происходить с пакетом в догоняющем
репозитории? Наверное, если им не будут заниматься и он будет FTBFS, то
он должен быть автоматически оттуда удалён.


Подробная информация о списке рассылки Devel