[devel] distro support TZ [was: Концепция политики разработки дистрибутивов ALT Linux]

[Igor Vlasenko]

On Tue, Jul 29, 2008 at 12:20:43PM +0400, Андрей Черепанов wrote:
> > Андрей, хотел бы подчеркнуть, что ресурс есть,
> > это community. Не надо его недооценивать.
> > Проблема в том, что он не используется, уходит в песок,
> > как вода из разбитого водопровода.
> > (из-за сломанной инфраструктуры).
> Комуннити - замечательный и очень ценный ресурс. Проблема в том, что этот 
> ресурс не хочет или не может заниматься таким неблагодарным делом, как 
> бэкпортирование.

Не верно. 
Как видно по http://backports.altlinux.org/,
В свое время для 2.4 работала большая команда, больше 70 человек,
которая поддерживала в backports более 400 пакетов.

Но потом сломалась инфраструктура (перестал работать backports incoming)
Как выяснилось в конце концов, 
см. http://lists.altlinux.org/pipermail/devel/2007-March/055334.html
К тому времени народ давно пообламывался, поскольку заливаешь пакеты,
а в ответ ничего...

Сейчас Миша тянет backports incoming, но это неблагодарный труд
(там все устарело, не по наслышке знаю. так как в свое время
Мише немного помогал).

> Давайте обсудим, что именно мешает этим заниматься? Инфраструктура? Опасения 
> ldv@? Я потому и затеял всю эту бучу, чтобы хоть как-то формализовать 
> процессы. И жду предложений от сообщества, что конкретно хочется.
> Что нужно для этого? Из сказанного я понимаю, что виновата инфраструктура?
> Что нужно в ней исправить?

Предлагаю следующее TZ по воссозданию сломанного:

1) Добавить backports/4.0/x86_64 и backports/4.1/x86_64

2) Допилить скрипты инкоминга, чтобы они автоматически 
обслуживали incoming/backports/x.x/

3) Поднять новые сайты с backports через prometeus:
http://backports-3.0.altlinux.org/
http://backports-4.0.altlinux.org/
http://backports-4.1.altlinux.org/
а http://backports.altlinux.org/ переименовать в
http://backports-2.4.altlinux.org/.
(В этом пункте могу помочь)

> Если пакеты будут попадать в бранч проверенными, то смысла делать updates нет 
> никакого. 
Вывод:
4) Убить updates/4.0 и updates/4.1 
или сделать симлинками на 4.0/branch 4.1/branch)
или внятно разъяснить, чем они отличаются от 4.0/branch 4.1/branch
и какие там правила доступа.

> А в бранч ты можешь положить чужой пакет. 
8( 
поверить не могу.
Неужели "прямщас" могу взять и залить gcc или там glibc
в incoming/updates/4.0?
И автоматика меня пропустит?
Где это документировано?
А майнтайнеры об этом знают?
А они с этим согласны?

Ведь по отношению к бранчам одни майнтайнеры "знают о этих
бранчах только то, что они где-то там как-то там когда-то там были
откуда-то там скопированы и существуют".
Такие майнтайнеры будут только рады, если допиливанием/перекладыванием
пакетов в бранче займется кто-то другой.

Другие наоборот хотят сами сопровождать свои пакеты в бранчах
(Не во всех, а в каких-то: например, на 2.2- 3.0 наплевать, 
пусть кладут что хотят, хоть гори оно синим пламенем, 
но 4.0-4.1 трогать не дам, а то сломают что-то.)

Следовательно кроме backports policy (в backports отсутствует ACL)

5) Нужно branch updates policy, в котором выписаны процедуры,
как можно положить в branch чужой пакет.

Например, создать updates team с правом выкладывать в branch любой пакет, 
либо, например, принять разрешение по умолчанию:

за 3 дня до upload пишется письмо в branch-updates@ и майнтайнеру.
если не было возражений, то разрешение по умолчанию.

6) кроме  branch updates policy завести
список рассылки branch-updates@
и поднять новые сайты с branch через prometeus:
http://branch-4.0.altlinux.org/
http://branch-4.1.altlinux.org/

Напомню, что полноценный дистрибутив отличается от 
стабильного среза сизифа за XX-YY-ZZZZ 
именно _поддержкой_.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine