Bug 49104

Summary: Кто такой "сопровождающий"?
Product: Infrastructure Reporter: Grigory Ustinov <grenka>
Component: packages.altlinux.orgAssignee: Danil Shein <dshein>
Status: NEW --- QA Contact: Andrey Cherepanov <cas>
Severity: normal    
Priority: P5 CC: iv, ldv, rider
Version: unspecified   
Hardware: x86   
OS: Linux   
Bug Depends on: 41023    
Bug Blocks:    

Description Grigory Ustinov 2024-01-17 18:02:05 MSK
С давних пор, ещё на сайте sisyphus.ru сайт выводил топ мейнтейнеров (или как нынче модно говорить по-славянски сопровождающих). Сейчас эту функцию давно уже убрали, хоть и было бы интересно посмотреть кто пакетирует как пчела. Короче я накидал скриптик на python, который сортирует это безобразие и у меня возникли вопросы к количеству "своих" пакетов.

Представьте моё удивление, когда я открыл https://packages.altlinux.org/ru/sisyphus/srpms/boost
А там я мейнтейнер. Какого лешего спрашивается? Иван Мельников обновляет этот пакет в поте лица, я сделал маленькое NMU и теперь сопровождающий?

Предлагаю пересмотреть алгоритмы вычисления сопровождающих. Такой результат корректным ни в каком приближении назвать нельзя.
Comment 1 Danil Shein 2024-01-17 18:07:38 MSK
Всё упирается в решение вопроса о том, кого и по какому признаку считать сопровождающим:

https://bugzilla.altlinux.org/41023
https://bugzilla.altlinux.org/41942
Comment 2 Grigory Ustinov 2024-01-17 18:46:14 MSK
"А сопровождающего пакет можно вычислить по changelog, используя для этого не очень сложную формулу." (с) rider@ https://bugzilla.altlinux.org/show_bug.cgi?id=41023#c2

Если задачу не могут решить уже несколько лет, имеет смысл попробовать разбить её на простые подзадачи:
1.) Найти бедолагу, ответственного за решение задачи
2.) Почистить мейнтейнеров, которые больше не мейтейнеры
3.) Опционально: роботом убрать поле Packager во всех пакетах, если это так уж необходимо
4.) Написать "не очень сложную" формулу
5.) ???????
6.) PROFIT!

По-хорошему после процедуры провести синхронизацию полученного списка со списком acl. Или даже наоборот, сначала сделать список acl, основываясь на частоте вносимых изменений и их актуальности, а уже из него лидеров ацл назначить сопровождающими.
Comment 3 Anton Farygin 2024-01-18 08:53:17 MSK
Давайте для начала в параллельных задачах придём к консолидированному мнению - кто и как должен считаться сопровождающим пакета. 

А дальше уже будет всё остальное.
Т.к. консолидированного мнения нет, то сейчас используется старая схема с Packager, а в интерфейсах просмотра пакетов приходится городить разные фильтры:

https://packages.altlinux.org/en/p10/maintainers/grenka/srpms?by_acl=nick_group
Comment 4 Anton Farygin 2024-01-18 08:54:52 MSK
Что касается чистки ментейнеров, которые уже не ментейнеры - нужно везде активно удалять поле Packager, заполенненое неправильно. И приводить в порядок acl на пакеты.

Мне кажется, что тут нужно услышать какое-то мнение от Димы.
Comment 5 Grigory Ustinov 2024-01-19 13:36:19 MSK
В мире айти всё довольно быстро движется вперёд. Поэтому начальной проверкой алгоритма пусть будет:
* обновлялся ли пакет за последние N лет? (допустим N=5)
- нет - nobody@
- да - идём далее
Берём записи ченджлога за последние N лет (либо последние M=15 записей) и создаём два списка авторов изменений за вычетом записей содержащих NMU. В одном списке авторы делавшие релизы alt0* и alt1 - то есть авторы "обновлений", во втором авторы всех остальных изменений "патчи, фиксы и т.п.". Рядом с каждым ником ставим в соответствие количество таких записей и сортируем оба списка по убыванию. Естественно делаем джойн по нику и если он существует в двух списках, то переносим его труды из изменений в обновления.
* лидер пакета - человек с наибольшим числом из этих двух списков. Если этот человек из списка "фиксеров", вторым в ацл идёт первый из списка "обновлявших", дальше в порядке убывания до K=3. Естественно приоритет за людьми из списка "обновлявших".

Понятное дело, что переменные N, M, K можно выбрать свои.

Не претендую на истинность, но это можно обсудить с контрпримерами, где этот алгоритм сработает не так, как хотелось бы и вместе конструктивно доработать!
Comment 6 Grigory Ustinov 2024-01-19 13:38:49 MSK
не "либо последние M=15", а "не более последних М=15"