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

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

[Андрей Черепанов]

На странице http://freesource.info/wiki/AltLinux/Branches/ReleasePolitic
выложено описание политики выпуска бранчей ALT Linux и дистрибутивов на их 
основе.

Вкратце:
Раз в полгода (сентябре и марте) делается новый бранч из Сизифа. В течение 
пяти месяцев он активно дорабатывается мейнтейнерами, релиз-менеджерами и 
отделом контроля качества. Для этого:
1. Дистрибутивы (альфа-версии) выпускаются сразу же после создания бранча
2. Релиз-менеджеры и отдел контроля качества вместе с мейнтенерами 
дорабатывают пакетную базу и дистрибутивы. Параллельно пишется техническое 
задание и ведётся список изменений.
3. За месяц до стабилизации пакеты попадают в бранч только после проверки 
отделом контроля качества.
4. После стабилизации для бранча выпускаются только обновления по безопасности 
и на этом бранче печатаются дистрибутивы.

Прошу высказываться.

P.S. Кросс-пост в comunnity@, devel@ и sisyphus@

-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

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

[Mikhail Gusarov]

Twas brillig at 15:21:02 28.07.2008 UTC+04 when cas@altlinux.ru did gyre and gimble:

 АЧ> На странице http://freesource.info/wiki/AltLinux/Branches/ReleasePolitic

Зачем ещё одна страница? Уже есть одна.

-- 

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

[Mikhail A. Pokidko]

2008/7/28 Андрей Черепанов :
> Вкратце:
> Раз в полгода (сентябре и марте) делается новый бранч из Сизифа. В течение
> пяти месяцев он активно дорабатывается мейнтейнерами, релиз-менеджерами и
> отделом контроля качества. Для этого:
> 1. Дистрибутивы (альфа-версии) выпускаются сразу же после создания бранча
> 2. Релиз-менеджеры и отдел контроля качества вместе с мейнтенерами
> дорабатывают пакетную базу и дистрибутивы. Параллельно пишется техническое
> задание и ведётся список изменений.

Какая-то странная последовательность - "давайте сделаем дистрибутив, а
потом подумаем зачем он нам и что он должен уметь"



-- 
xmpp: pma AT altlinux DOT org

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

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

* Mikhail A. Pokidko <mikhail.pokidko@> [080728 15:44]:
> Какая-то странная последовательность - "давайте сделаем дистрибутив, а
> потом подумаем зачем он нам и что он должен уметь"
Проще всем привыкнуть раз в пол года делать бранч, чем кому-то
одному пинать всех мантейнеров чтобы они свои пакеты починили
ПРЯМЩАС, потому что этому человеку срочно понадобилось делать
дистрибутив.

Меня больше интересует процесс "стабилизации".  Пакеты хочется
всё-таки перекладывать, а не мучительно бэкпортировать...

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Yuri N. Sedunov]

В Пнд, 28/07/2008 в 15:57 +0400, Alexey I. Froloff пишет:
> * Mikhail A. Pokidko <mikhail.pokidko@> [080728 15:44]:
<skip>
> 
> Меня больше интересует процесс "стабилизации".  Пакеты хочется
> всё-таки перекладывать, а не мучительно бэкпортировать...

+100 
-- 
Yuri N. Sedunov

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

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 2265 bytes --]

Twas brillig at 15:40:00 28.07.2008 UTC+04 when mikhail.pokidko@gmail.com did gyre and gimble:

 MAP> 2008/7/28 Андрей Черепанов :
 >> Вкратце:
 >> Раз в полгода (сентябре и марте) делается новый бранч из Сизифа. В течение
 >> пяти месяцев он активно дорабатывается мейнтейнерами, релиз-менеджерами и
 >> отделом контроля качества. Для этого:
 >> 1. Дистрибутивы (альфа-версии) выпускаются сразу же после создания бранча
 >> 2. Релиз-менеджеры и отдел контроля качества вместе с мейнтенерами
 >> дорабатывают пакетную базу и дистрибутивы. Параллельно пишется техническое
 >> задание и ведётся список изменений.

 MAP> Какая-то странная последовательность - "давайте сделаем
 MAP> дистрибутив, а потом подумаем зачем он нам и что он должен уметь"

Тут обратная связь: бранчевание регулярное, а разработка - не совсем,
поэтому понять, что конкретно можно сделать на каждом бранче, можно
только незадолго до того, как этот бранч будет сделан.

Соответственно, написание (точнее, не написание, а конкретизация) ТЗ
будет включать в себя вещи, которые неизвестны заранее. К примеру, если
к созданию бранча допилили pulseaudio в качестве замены esd и прочим
звуковым демонам, то в ТЗ вносится "pulseaudio основной звуковой
системой", а если не допилили и допилить явно не получится - значит
такого пункта в ТЗ не будет.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 368 bytes --]

On Mon, Jul 28, 2008 at 06:23:34PM +0700, Mikhail Gusarov wrote:
> Twas brillig at 15:21:02 28.07.2008 UTC+04 when cas@altlinux.ru did gyre and gimble:
> 
>  АЧ> На странице http://freesource.info/wiki/AltLinux/Branches/ReleasePolitic
> 
> Зачем ещё одна страница? Уже есть одна.

Действительно, зачем плодить сущности без видимой необходимости?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Андрей Черепанов]

28 июля 2008 Mikhail A. Pokidko написал:
> 2008/7/28 Андрей Черепанов :
> > Вкратце:
> > Раз в полгода (сентябре и марте) делается новый бранч из Сизифа. В
> > течение пяти месяцев он активно дорабатывается мейнтейнерами,
> > релиз-менеджерами и отделом контроля качества. Для этого:
> > 1. Дистрибутивы (альфа-версии) выпускаются сразу же после создания бранча
> > 2. Релиз-менеджеры и отдел контроля качества вместе с мейнтенерами
> > дорабатывают пакетную базу и дистрибутивы. Параллельно пишется
> > техническое задание и ведётся список изменений.
>
> Какая-то странная последовательность - "давайте сделаем дистрибутив, а
> потом подумаем зачем он нам и что он должен уметь"
Это временная мера для следующего бранча, так как по факту ТЗ нет ни для 
одного дистрибутива. Когда-то нужно делать. После того, как будет сделано по 
одному нормальному ТЗ, оно будет лишь дорабатываться, стабилизируясь на 5 
месяц жизни бранча.

-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

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

[Андрей Черепанов]

28 июля 2008 Alexey I. Froloff написал:
> * Mikhail A. Pokidko <mikhail.pokidko@> [080728 15:44]:
> > Какая-то странная последовательность - "давайте сделаем дистрибутив, а
> > потом подумаем зачем он нам и что он должен уметь"
>
> Проще всем привыкнуть раз в пол года делать бранч, чем кому-то
> одному пинать всех мантейнеров чтобы они свои пакеты починили
> ПРЯМЩАС, потому что этому человеку срочно понадобилось делать
> дистрибутив.
>
> Меня больше интересует процесс "стабилизации".  Пакеты хочется
> всё-таки перекладывать, а не мучительно бэкпортировать...
Стабилизация == доступность только для security fix. И только для них.

-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

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

[Led]

В сообщении от Monday 28 July 2008 17:19:02 Андрей Черепанов написал(а):
> 28 июля 2008 Alexey I. Froloff написал:
> > * Mikhail A. Pokidko <mikhail.pokidko@> [080728 15:44]:
> > > Какая-то странная последовательность - "давайте сделаем дистрибутив, а
> > > потом подумаем зачем он нам и что он должен уметь"
> >
> > Проще всем привыкнуть раз в пол года делать бранч, чем кому-то
> > одному пинать всех мантейнеров чтобы они свои пакеты починили
> > ПРЯМЩАС, потому что этому человеку срочно понадобилось делать
> > дистрибутив.
> >
> > Меня больше интересует процесс "стабилизации".  Пакеты хочется
> > всё-таки перекладывать, а не мучительно бэкпортировать...
>
> Стабилизация == доступность только для security fix. И только для них.

Не вижу причин закрывать бранч для просто (не security) fix'ов (без добавления 
новых фич)

-- 
Led

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

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 399 bytes --]

* Андрей Черепанов <cas@> [080728 18:26]:
> > Меня больше интересует процесс "стабилизации".  Пакеты хочется
> > всё-таки перекладывать, а не мучительно бэкпортировать...
> Стабилизация == доступность только для security fix. И только для них.
Т.е. если Некая Хрень в данном бранче не работает или работает
плохо, эта Хрень считается в этом бранче несуществующей?

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Андрей Черепанов]

28 июля 2008 Led написал:
> В сообщении от Monday 28 July 2008 17:19:02 Андрей Черепанов написал(а):
> > 28 июля 2008 Alexey I. Froloff написал:
> > > * Mikhail A. Pokidko <mikhail.pokidko@> [080728 15:44]:
> > > > Какая-то странная последовательность - "давайте сделаем дистрибутив,
> > > > а потом подумаем зачем он нам и что он должен уметь"
> > >
> > > Проще всем привыкнуть раз в пол года делать бранч, чем кому-то
> > > одному пинать всех мантейнеров чтобы они свои пакеты починили
> > > ПРЯМЩАС, потому что этому человеку срочно понадобилось делать
> > > дистрибутив.
> > >
> > > Меня больше интересует процесс "стабилизации".  Пакеты хочется
> > > всё-таки перекладывать, а не мучительно бэкпортировать...
> >
> > Стабилизация == доступность только для security fix. И только для них.
>
> Не вижу причин закрывать бранч для просто (не security) fix'ов (без
> добавления новых фич)
Ну тогда нет смысла выпускать качественные дистрибутивы на этом бранче.

-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

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

[Андрей Черепанов]

28 июля 2008 Alexey I. Froloff написал:
> * Андрей Черепанов <cas@> [080728 18:26]:
> > > Меня больше интересует процесс "стабилизации".  Пакеты хочется
> > > всё-таки перекладывать, а не мучительно бэкпортировать...
> >
> > Стабилизация == доступность только для security fix. И только для них.
>
> Т.е. если Некая Хрень в данном бранче не работает или работает
> плохо, эта Хрень считается в этом бранче несуществующей?
Почему, она и считается неработающей или криво работающей. И на исправление 
этого даётся 6 месяцев или ожидание следующего бранча.


-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

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

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 803 bytes --]

Twas brillig at 18:34:05 28.07.2008 UTC+04 when raorn@altlinux.ru did gyre and gimble:

 >> Стабилизация == доступность только для security fix. И только для них.

 AIF> Т.е. если Некая Хрень в данном бранче не работает или работает
 AIF> плохо, эта Хрень считается в этом бранче несуществующей?

Так бранч-то стабилизируется только через 5 месяцев после ответвления, и
за это время на нём куча альф выпускается, так что Все Хрени можно
попробовать, понять, какие не работают и пофиксить.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

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

[Igor Vlasenko]

On Mon, Jul 28, 2008 at 05:28:48PM +0300, Led wrote:
> В сообщении от Monday 28 July 2008 17:19:02 Андрей Черепанов написал(а):
> > > Меня больше интересует процесс "стабилизации".  Пакеты хочется
> > > всё-таки перекладывать, а не мучительно бэкпортировать...
> >
> > Стабилизация == доступность только для security fix. И только для них.
> 
> Не вижу причин закрывать бранч для просто (не security) fix'ов (без добавления 
> новых фич)
+10.
В fedora updates не стесняются и новые версии класть...

в 4.0 было сделано продуманно:
по факту был сизиф, общий бранч, и (частично) бранч дистрибутива.
И пакеты перекладывались по цепочке.
Из сизифа в бранч майнтайнерами, а из бранча брались
в дистрибутив выпускающими.

IMHO, если в бранч будет геморройно ложить просто фиксы,
то тем более будет геморройно ложить и security fixы.

Вон 4.1 лежит трупом, трафик в нем такой же, как и в 4.0
а должен был быть на порядок больше 
:(

Дистрибутив мало выпустить. Его еще 
сопровождать нужно. А если с updates геморрой,
backports Миша руками тянет, и то они по сути мертвые
(трафик упал по сравнению с 2.2/2.4 на два порядка)

IMHO, выпуск дистрибутивов важен, но не менее важна
поддержка.

-- 

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

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

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 815 bytes --]

* Андрей Черепанов <cas@> [080728 18:47]:
> > Т.е. если Некая Хрень в данном бранче не работает или работает
> > плохо, эта Хрень считается в этом бранче несуществующей?
> Почему, она и считается неработающей или криво работающей. И на исправление 
> этого даётся 6 месяцев или ожидание следующего бранча.
Да, я неправильно высказался.  Месяц бэкпортов это нормально, но
вот пять месяцев хотелось бы пакеты просто перекладывать.
Насколько сложно совместить "стабилизацию" бранча и полный разлом
сизифа?

Или даже так.  "Стабилизируем" сизиф и делаем бранч.  После чего
в сизиф отправляются все новые экспериментальные наработки, а
бранч параллельно "стабилизируется" до дистрибутивного состояния.
Сизиф оказывается "вусмерть разломаным" не больше двух месяцев в
году ;-)

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Igor Vlasenko]

On Mon, Jul 28, 2008 at 09:43:27PM +0700, Mikhail Gusarov wrote:
> Twas brillig at 18:34:05 28.07.2008 UTC+04 when raorn@altlinux.ru did gyre and gimble:
> 
>  >> Стабилизация == доступность только для security fix. И только для них.
> 
>  AIF> Т.е. если Некая Хрень в данном бранче не работает или работает
>  AIF> плохо, эта Хрень считается в этом бранче несуществующей?
> 
> Так бранч-то стабилизируется только через 5 месяцев после ответвления, и
> за это время на нём куча альф выпускается, так что Все Хрени можно
> попробовать, понять, какие не работают и пофиксить.

это было бы прекрасно, но безглючных дистрибутивов нет, 
да и апстримы не живут по графику :(

Эта точка зрения не учитвывет интересов конечного пользователя.
Он ставит _уже_ выпущенный дистрибутив, находит 
в нем глюки, возникает желание их исправить.

Очень продвинутые пользователи собрали бы в backports
(у меня времени нет это самому пробить, 
но отсутствие backports/x86_64 - гвоздь в ботинке)

Менее заинтересованные или продвинутые
попросили бы через Багзиллу это сделать майнтайнера.

и тут нас ждет неприятный сюрприз в виде новой
"Концепции политики разработки дистрибутивов ALT Linux"

-- 

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

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

[Igor Vlasenko]

On Mon, Jul 28, 2008 at 07:10:00PM +0400, Alexey I. Froloff wrote:
> * Андрей Черепанов <cas@> [080728 18:47]:
> > > Т.е. если Некая Хрень в данном бранче не работает или работает
> > > плохо, эта Хрень считается в этом бранче несуществующей?
> > Почему, она и считается неработающей или криво работающей. И на исправление 
> > этого даётся 6 месяцев или ожидание следующего бранча.
> Да, я неправильно высказался.  Месяц бэкпортов это нормально, но
> вот пять месяцев хотелось бы пакеты просто перекладывать.
> Насколько сложно совместить "стабилизацию" бранча и полный разлом
> сизифа?
> 
> Или даже так.  "Стабилизируем" сизиф и делаем бранч.  После чего
> в сизиф отправляются все новые экспериментальные наработки, а
> бранч параллельно "стабилизируется" до дистрибутивного состояния.
> Сизиф оказывается "вусмерть разломаным" не больше двух месяцев в
> году ;-)
+1

-- 

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

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

[Igor Vlasenko]

On Mon, Jul 28, 2008 at 06:12:02PM +0300, Igor Vlasenko wrote:
> > Так бранч-то стабилизируется только через 5 месяцев после ответвления, и
> > за это время на нём куча альф выпускается, так что Все Хрени можно
> > попробовать, понять, какие не работают и пофиксить.
> 
> это было бы прекрасно, но безглючных дистрибутивов нет, 
> да и апстримы не живут по графику :(

Другими словами, не верится, что 
"Релиз-менеджеры и отдел контроля качества вместе с мейнтенерами
доработают пакетную базу и дистрибутивы" до безглючного состояния.

Верится скорее в то, что пользователи глюки найдут.

И хотелось бы их как-то фиксить, не дожидаясь
"ожидание следующего бранча + 6 месяцев".

Работать то сейчас надо.
Кроме того, бывают feature/performance updates.

Вот я в 4.0 выложил java6 update 7. 
И кто я теперь, диверсант?

-- 

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

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

[Андрей Черепанов]

28 июля 2008 Igor Vlasenko написал:
> Эта точка зрения не учитвывет интересов конечного пользователя.
> Он ставит _уже_ выпущенный дистрибутив, находит
> в нем глюки, возникает желание их исправить.
>
> Очень продвинутые пользователи собрали бы в backports
> (у меня времени нет это самому пробить,
> но отсутствие backports/x86_64 - гвоздь в ботинке)
>
> Менее заинтересованные или продвинутые
> попросили бы через Багзиллу это сделать майнтайнера.
>
> и тут нас ждет неприятный сюрприз в виде новой
> "Концепции политики разработки дистрибутивов ALT Linux"
Это может быть нивелировано только с появлением нормально сопровождаемого 
backports. Или советом переходить на sisyphus. Так как у нас нет ресурсов для 
широкого бэкпортирования, то и не стОит ждать функциональных обновлений. Или 
же будем выпускать дистрибутивы на Сизифе, напрочь игнорируя бранчи, которые 
будут служить непонятно чему. Наверно, интеллектуальным играм мейнтейнеров, 
как сейчас 4.1.


-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

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

[Андрей Черепанов]

28 июля 2008 Igor Vlasenko написал:
> Вот я в 4.0 выложил java6 update 7.
> И кто я теперь, диверсант?
Нет, молодец. Готов также перекладывать всё остальное?

-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

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

[Igor Vlasenko]

On Mon, Jul 28, 2008 at 07:34:25PM +0400, Андрей Черепанов wrote:
> Это может быть нивелировано только с появлением нормально сопровождаемого 
> backports. Или советом переходить на sisyphus. 
> Так как у нас нет ресурсов для 
> широкого бэкпортирования, то и не стОит ждать функциональных обновлений. 

Андрей, хотел бы подчеркнуть, что ресурс есть,
это community. Не надо его недооценивать. 
Проблема в том, что он не используется, уходит в песок,
как вода из разбитого водопровода.
(из-за сломанной инфраструктуры).

Поясню на примере себя. Я сижу на бранче 4.0 (x86_64)
(когда выйдет 4.1, перелезу туда).
Поскольку я в нем работаю, неизбежно приходится сопровождать.
Что-то собираю и для себя, но поделиться не могу,
поскольку ложить в updates чужие пакеты я, как "тварь дрожащая, права не имею"
а в backports нет x86_64. 
Сам разгрести инфраструктуру backports тоже не могу,
все время уходит на java* :(

Так мои усилия уходят в песок.
А ведь если бы появились 1-2 активных бакпортера,
backports ожили бы, туда бы потянулись еще люди.
и было бы широкого бэкпортирования, как раньше в master 2.0-2.4.

> Или 
> же будем выпускать дистрибутивы на Сизифе, напрочь игнорируя бранчи, которые 
> будут служить непонятно чему. Наверно, интеллектуальным играм мейнтейнеров, 
> как сейчас 4.1.

Опять же это из-за сломанной инфраструктуры.
За примерами ходить не далеко.

4.0 был очень даже живой бранч,
из-за того, что можно было легко перекладывать
пакеты из Сизифа в бранч.

4.1 тоже был живой, пока не вышел rpm c lzma. 
Было бы правильно, если бы его переложили в 4.1.

Я считаю, что неперекладывание нового rpm c lzma
в 4.1 и есть причина того, что бранч 4.1 служит непонятно чему,
"Наверно, интеллектуальным играм мейнтейнеров."

Сломалась удобная инфраструктура прямого перекладывания,
и бранч засох вместе с ней.

Только мне кажется, что не мейнтейнеров надо винить.
-- 

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

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

[Igor Vlasenko]

On Mon, Jul 28, 2008 at 07:35:17PM +0400, Андрей Черепанов wrote:
> 28 июля 2008 Igor Vlasenko написал:
> > Вот я в 4.0 выложил java6 update 7.
> > И кто я теперь, диверсант?
> Нет, молодец. Готов также перекладывать всё остальное?

Крайне большой геморрой. Это обсуждалось в
https://bugzilla.altlinux.org/show_bug.cgi?id=15393
(Заявка на перенос около 100 пакетов из Сизифа в 4.0)
[пропущнен список пакетов]
------- Comment  #4 From viy  2008-04-23 12:19:00  [reply] -------

ldv> Как вы вычисляете это множество пакетов, как проверяете его?
Это стабильный срез java-подсистемы сизифа минус срез бранча.

ldv> Игорь, поймите меня правильно:
ldv> на этой стадии переносить такую прорву пакетов из Сизифа в бранч просто страшно.

единственный безопасный способ переноса, который у меня есть :(
Я планирую писать различные тестеры, начиная с тестов под repocop,
но еще не дошел :(

java-подсистема сизифа очень слабо связана с остальным Сизифом, практически
только косвенно в одну сторону (зависимость на Сизиф) через arch-пакеты
наподобие eclipse.

переносить java пакеты по одному не могу, так как нет ни никаких гарантий
backward совместимости, ни тестов (надеюсь, будут).

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

Я переноса пакетов по одному боюсь на порядок больше, чем переноса 
срезом. 

Пока единственную гарантию дает перенос стабильными срезами.

Имеющаяся ветка в Сизифе (основана на стабильном jpackage 1.7) заморожена, 
я в ней только правлю ошибки.
Что-то новое заливать думаю не ранее отпочкования ветки 4.1.
Этот срез лучше того, что в бранче 4.0.

Единственная возможная грабля - это arch пакеты
(в данном случае eclipse) которые могут породить обычные сишные unmets.
Но это не страшно, я проверю eclipse после перекладывания и при необходимости
пересоберу его через updates.

Почему я не могу пересобрать один eclipse - там правились и менялись другие 
нужные ему java noarch пакеты, ant, lucene*, tomcat5, jakarta-commons-{some},
jetty5 и т. д. Нужно обновить сначала java noarch.



-- 

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

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

[Igor Vlasenko]

On Mon, Jul 28, 2008 at 07:23:53PM +0300, Igor Vlasenko wrote:
> Сломалась удобная инфраструктура прямого перекладывания,
> и бранч засох вместе с ней.

Одним словом, 
как бы хорошо не проектировали паровоз,
он не поедет, если партизаны разобрали рельсы.

-- 

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

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

[Led]

В сообщении от Monday 28 July 2008 19:39:21 Igor Vlasenko написал(а):
> On Mon, Jul 28, 2008 at 07:23:53PM +0300, Igor Vlasenko wrote:
> > Сломалась удобная инфраструктура прямого перекладывания,
> > и бранч засох вместе с ней.
>
> Одним словом,
> как бы хорошо не проектировали паровоз,
> он не поедет, если партизаны разобрали рельсы.

Другими словами: если в бранч хочется что-то удобно перекладывать откуда-то, 
то нужно адаптировать бранч под это "откуда-то" (Сизиф), а не наоборот.

-- 
Led

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

[Denis Ovsienko]

[...]

> Вон 4.1 лежит трупом, трафик в нем такой же, как и в 4.0
> а должен был быть на порядок больше 
> :(

Должен??? Порядочная часть тех, кто этот трафик создаёт, знает о этих
бранчах только то, что они где-то там как-то там когда-то там были
откуда-то там скопированы и существуют. Когда торжественно появится
следующий бранч, они прочитают, кивнут и займутся дальше своими делами
(и будут правы). Не нужно ждать чего-то от разработчиков, которым не
объяснили, чего от них ждут.

-- 
    DO4-UANIC

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

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 579 bytes --]

On Mon, Jul 28, 2008 at 07:10:00PM +0400, Alexey I. Froloff wrote:
> Или даже так.  "Стабилизируем" сизиф и делаем бранч.  После чего
> в сизиф отправляются все новые экспериментальные наработки, а
> бранч параллельно "стабилизируется" до дистрибутивного состояния.
> Сизиф оказывается "вусмерть разломаным" не больше двух месяцев в
> году ;-)
Я это раз в полгода слышу последние года 2-3, по-моему.


-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

Лучше конференций могут быть только конференции,
на которых ещё не бывал.
		-- at in devel@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Anton Farygin]

Андрей Черепанов пишет:
> 28 июля 2008 Alexey I. Froloff написал:
>> * Андрей Черепанов <cas@> [080728 18:26]:
>>>> Меня больше интересует процесс "стабилизации".  Пакеты хочется
>>>> всё-таки перекладывать, а не мучительно бэкпортировать...
>>> Стабилизация == доступность только для security fix. И только для них.
>> Т.е. если Некая Хрень в данном бранче не работает или работает
>> плохо, эта Хрень считается в этом бранче несуществующей?
> Почему, она и считается неработающей или криво работающей. И на исправление 
> этого даётся 6 месяцев или ожидание следующего бранча.

Т.е. - срок поддержки дистрибутивов, выпущенных на бранче - 6 месяцев ?

Вопрос: что делать с пакетом, который существует во всех бранчах, и в 
новой версии которого исправили критическую для пакета (но не security) 
ошибку ?

Собственно изменение версии произошло только для исправления этой ошибки....

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

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 764 bytes --]

On Mon, Jul 28, 2008 at 09:17:01PM +0400, Denis Ovsienko wrote:
> Должен??? Порядочная часть тех, кто этот трафик создаёт, знает о этих
> бранчах только то, что они где-то там как-то там когда-то там были
> откуда-то там скопированы и существуют. Когда торжественно появится
> следующий бранч, они прочитают, кивнут и займутся дальше своими делами
> (и будут правы). 
+1
Тем более я этими бранчами не пользуюсь и даже устанавливаемость
тестировать не могу и не хочу.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

Поддержка vlan'ов у нас появилась в середине 2002-го года, в RH -
только в начале 2003-го, в MDK - из RH.

Можете спросить в RH, почему они сделали несовместимый с ALT Linux
интерфейс.
		-- ldv in sisyphus@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 799 bytes --]

* Denis Ovsienko <pilot@> [080728 21:19]:
> Не нужно ждать чего-то от разработчиков, которым не объяснили,
> чего от них ждут.
Вот лично мне не очень интересно поддерживать свои пакеты в
бранче по одной простой причине - я им не пользуюсь.  Зато
пользуюсь сизифом.  Если я вдруг узнаю, что завтра в сизиф уйдёт
новый тулчейн, ксорг, ядро и гном, то пару недель я точно не буду
обновляться.  Хотя бы до тех пор, пока оно не будет собираться и
ставиться.  И текущий "отфорченый" бранч я вполне смогу в это
время отправлять исправления (но в прошлый/позапрошлый мне это
будет делать сложно и лень).

Впрочем, это то же самое что и провалившаяся схема Sync/Freeze.

Тем кто постоянно живёт на сизифе бранч неинтересен, тем кто
живёт на бранчах - сизиф уныл.

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Igor Vlasenko]

On Mon, Jul 28, 2008 at 09:17:01PM +0400, Denis Ovsienko wrote:
> [...]
> 
> > Вон 4.1 лежит трупом, трафик в нем такой же, как и в 4.0
> > а должен был быть на порядок больше 
> > :(
> 
> Должен??? Порядочная часть тех, кто этот трафик создаёт, знает о этих
> бранчах только то, что они где-то там как-то там когда-то там были

Я имел в виду майнтайнеров, которые хотят, но не могут.
Т.е. например, себя. В 4.0, пока была возможность, мог
себе позволить переложить 100 пакетов за транзакцию.
А сейчас не могу :( - Cм. предыдущее письмо.

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

Речь не шла о том чтобы кого-то заставлять такого,
кто в этой деятельности не заинтересован.

-- 

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

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

[Anton V. Boyarshinov]

On Mon, 28 Jul 2008 17:58:17 +0300 Igor Vlasenko wrote:

> в 4.0 было сделано продуманно:
> по факту был сизиф, общий бранч, и (частично) бранч дистрибутива.
> И пакеты перекладывались по цепочке.
> Из сизифа в бранч майнтайнерами, 
> а из бранча брались в дистрибутив выпускающими.
Последняя строчка неверна. Дистрибутивы собирались и собираются
непосредственно из бранча

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

[Андрей Черепанов]

28 июля 2008 Anton Farygin написал:
> Андрей Черепанов пишет:
> > 28 июля 2008 Alexey I. Froloff написал:
> >> * Андрей Черепанов <cas@> [080728 18:26]:
> >>>> Меня больше интересует процесс "стабилизации".  Пакеты хочется
> >>>> всё-таки перекладывать, а не мучительно бэкпортировать...
> >>>
> >>> Стабилизация == доступность только для security fix. И только для них.
> >>
> >> Т.е. если Некая Хрень в данном бранче не работает или работает
> >> плохо, эта Хрень считается в этом бранче несуществующей?
> >
> > Почему, она и считается неработающей или криво работающей. И на
> > исправление этого даётся 6 месяцев или ожидание следующего бранча.
>
> Т.е. - срок поддержки дистрибутивов, выпущенных на бранче - 6 месяцев ?
>
> Вопрос: что делать с пакетом, который существует во всех бранчах, и в
> новой версии которого исправили критическую для пакета (но не security)
> ошибку ?
>
> Собственно изменение версии произошло только для исправления этой
> ошибки....
Тут два пути:
1. Если есть желание мейнтенера или человек, который может осуществлять 
бэкпортирование - то бэкпортировать на все бранчи.
2. (нынешнее состояние) ничего не выкладывать в бранчи

-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

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

[Андрей Черепанов]

28 июля 2008 Igor Vlasenko написал:
> On Mon, Jul 28, 2008 at 07:34:25PM +0400, Андрей Черепанов wrote:
> > Это может быть нивелировано только с появлением нормально сопровождаемого
> > backports. Или советом переходить на sisyphus.
> > Так как у нас нет ресурсов для
> > широкого бэкпортирования, то и не стОит ждать функциональных обновлений.
>
> Андрей, хотел бы подчеркнуть, что ресурс есть,
> это community. Не надо его недооценивать.
> Проблема в том, что он не используется, уходит в песок,
> как вода из разбитого водопровода.
> (из-за сломанной инфраструктуры).
Комуннити - замечательный и очень ценный ресурс. Проблема в том, что этот 
ресурс не хочет или не может заниматься таким неблагодарным делом, как 
бэкпортирование.
Давайте обсудим, что именно мешает этим заниматься? Инфраструктура? Опасения 
ldv@? Я потому и затеял всю эту бучу, чтобы хоть как-то формализовать 
процессы. И жду предложений от сообщества, что конкретно хочется.

> Поясню на примере себя. Я сижу на бранче 4.0 (x86_64)
> (когда выйдет 4.1, перелезу туда).
> Поскольку я в нем работаю, неизбежно приходится сопровождать.
> Что-то собираю и для себя, но поделиться не могу,
> поскольку ложить в updates чужие пакеты я, как "тварь дрожащая, права не
> имею" а в backports нет x86_64.
> Сам разгрести инфраструктуру backports тоже не могу,
> все время уходит на java* :(
Если пакеты будут попадать в бранч проверенными, то смысла делать updates нет 
никакого. А в бранч ты можешь положить чужой пакет. Но я прекрасно пойму, 
если ты не захочешь делать за мейнтенерами их работу.
Может, ввести практику двух Incoming: в Сизиф и обобщённый для всех бранчей. 
Или же помещать ВСЕ пакеты, идущие в Сизиф в пул кандидатов для бранчей. 
После этого или мейнтейнер или бэкпортер размещает это в бранчи.

> Так мои усилия уходят в песок.
> А ведь если бы появились 1-2 активных бакпортера,
> backports ожили бы, туда бы потянулись еще люди.
> и было бы широкого бэкпортирования, как раньше в master 2.0-2.4.
Что нужно для этого? Из сказанного я понимаю, что виновата инфраструктура?
Что нужно в ней исправить?

-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

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

[Anton Farygin]

Андрей Черепанов пишет:
> 28 июля 2008 Anton Farygin написал:
>> Андрей Черепанов пишет:
>>> 28 июля 2008 Alexey I. Froloff написал:
>>>> * Андрей Черепанов <cas@> [080728 18:26]:
>>>>>> Меня больше интересует процесс "стабилизации".  Пакеты хочется
>>>>>> всё-таки перекладывать, а не мучительно бэкпортировать...
>>>>> Стабилизация == доступность только для security fix. И только для них.
>>>> Т.е. если Некая Хрень в данном бранче не работает или работает
>>>> плохо, эта Хрень считается в этом бранче несуществующей?
>>> Почему, она и считается неработающей или криво работающей. И на
>>> исправление этого даётся 6 месяцев или ожидание следующего бранча.
>> Т.е. - срок поддержки дистрибутивов, выпущенных на бранче - 6 месяцев ?
>>
>> Вопрос: что делать с пакетом, который существует во всех бранчах, и в
>> новой версии которого исправили критическую для пакета (но не security)
>> ошибку ?
>>
>> Собственно изменение версии произошло только для исправления этой
>> ошибки....
> Тут два пути:
> 1. Если есть желание мейнтенера или человек, который может осуществлять 
> бэкпортирование - то бэкпортировать на все бранчи.

Естественно - бэкпорт, но непосредственно в бранчи. Собственно с 4.0 я 
так (иногда) поступал, когда был уверен в положительном результате.

Если мы схему изменим, то получим много минусов.

> 2. (нынешнее состояние) ничего не выкладывать в бранчи

Этот вариант не совсем корректен.

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

[Igor Vlasenko]

On Tue, Jul 29, 2008 at 12:32:17PM +0400, Anton Farygin wrote:
>> бэкпортирование - то бэкпортировать на все бранчи.
> Естественно - бэкпорт, но непосредственно в бранчи. Собственно с 4.0 я так 
> (иногда) поступал, когда был уверен в положительном результате.
>
> Если мы схему изменим, то получим много минусов.
+1
>> 2. (нынешнее состояние) ничего не выкладывать в бранчи
Звучит как-то непонятно.
Ведь сейчас же в бранчи можно выкладывать, и люди кладут...


-- 

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

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

[Андрей Черепанов]

29 июля 2008 Igor Vlasenko написал:
> On Tue, Jul 29, 2008 at 12:32:17PM +0400, Anton Farygin wrote:
> >> бэкпортирование - то бэкпортировать на все бранчи.
> >
> > Естественно - бэкпорт, но непосредственно в бранчи. Собственно с 4.0 я
> > так (иногда) поступал, когда был уверен в положительном результате.
> >
> > Если мы схему изменим, то получим много минусов.
>
> +1
>
> >> 2. (нынешнее состояние) ничего не выкладывать в бранчи
>
> Звучит как-то непонятно.
> Ведь сейчас же в бранчи можно выкладывать, и люди кладут...
Речь шла про будущие бранчи. Идея в том, чтобы давать выкладывать, чтобы это 
выкладывание не разломало всё.


-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

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

[Anton V. Boyarshinov]

> Может, ввести практику двух Incoming: в Сизиф и обобщённый для всех бранчей. 
Это как? Пакеты в разных бранчах могут иметь разыне зависимости,
местами разный код и обязаны иметь разные релизы.

[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

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

[Igor Vlasenko]

On Tue, Jul 29, 2008 at 02:08:36PM +0400, Андрей Черепанов wrote:
> 29 июля 2008 Igor Vlasenko написал:
> > >> 2. (нынешнее состояние) ничего не выкладывать в бранчи
> >
> > Звучит как-то непонятно.
> > Ведь сейчас же в бранчи можно выкладывать, и люди кладут...
> Речь шла про будущие бранчи. Идея в том, чтобы давать выкладывать, чтобы это 
> выкладывание не разломало всё.

я бы конкретизировал эту идею.
IMHO, в том, чтобы на время заморозить бранч, 
скажем, на месяц, перед релизом, 
и в это время принимать только magor bug/security fixes, 
нет ничего плохого.

Главное, чтобы не забыть разморозить, чтобы после релиза 
его можно было сопровождать.

-- 

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

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

[Anton V. Boyarshinov]

 
> поверить не могу.
> Неужели "прямщас" могу взять и залить gcc или там glibc
> в incoming/updates/4.0?
> И автоматика меня пропустит?
Залить можно. Автоматика -- пропустит. Но на пути в бранч есть ещё и
человек. Который может пропустить, а может -- нет.

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

[Igor Vlasenko]

On Tue, Jul 29, 2008 at 03:13:23PM +0400, Anton V. Boyarshinov wrote:
>  
> > поверить не могу.
> > Неужели "прямщас" могу взять и залить gcc или там glibc
> > в incoming/updates/4.0?
> > И автоматика меня пропустит?
> Залить можно. Автоматика -- пропустит. Но на пути в бранч есть ещё и
> человек. Который может пропустить, а может -- нет.

Следовательно, полиси нужно.
Соблюдая которoе, можно не опасаться зря потратить свое время.

-- 

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

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

[Anton Farygin]

Igor Vlasenko пишет:
> On Tue, Jul 29, 2008 at 03:13:23PM +0400, Anton V. Boyarshinov wrote:
>>  
>>> поверить не могу.
>>> Неужели "прямщас" могу взять и залить gcc или там glibc
>>> в incoming/updates/4.0?
>>> И автоматика меня пропустит?
>> Залить можно. Автоматика -- пропустит. Но на пути в бранч есть ещё и
>> человек. Который может пропустить, а может -- нет.
> 
> Следовательно, полиси нужно.
> Соблюдая которoе, можно не опасаться зря потратить свое время.

Именно. Основное в полиси должно быть:
если пакет ни на что не влияет, то его можно обновлять сколько угодно.

Всё остальное - на усмотрение мантейнера, IMHO. Ибо человек может не 
знать всех тонкостей рассматриваемого пакета.

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

[Igor Vlasenko]

On Tue, Jul 29, 2008 at 03:36:18PM +0400, Anton Farygin wrote:
>> Следовательно, полиси нужно.
>> Соблюдая которoе, можно не опасаться зря потратить свое время.
>
> Именно. Основное в полиси должно быть:
> если пакет ни на что не влияет, то его можно обновлять сколько угодно.
>
> Всё остальное - на усмотрение мантейнера, IMHO. Ибо человек может не знать 
> всех тонкостей рассматриваемого пакета.

Это тоже нужно разъяснить. 
1) какие пакеты ни на что не влияют (заливать без согласования с мантейнером)
2) как получить усмотрение мантейнера на пакеты, не входяшие в первый класс.

-- 

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

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

[Anton Farygin]

Igor Vlasenko пишет:
> On Tue, Jul 29, 2008 at 03:36:18PM +0400, Anton Farygin wrote:
>>> Следовательно, полиси нужно.
>>> Соблюдая которoе, можно не опасаться зря потратить свое время.
>> Именно. Основное в полиси должно быть:
>> если пакет ни на что не влияет, то его можно обновлять сколько угодно.
>>
>> Всё остальное - на усмотрение мантейнера, IMHO. Ибо человек может не знать 
>> всех тонкостей рассматриваемого пакета.
> 
> Это тоже нужно разъяснить. 
> 1) какие пакеты ни на что не влияют (заливать без согласования с мантейнером)

На мой взгляд, это пакеты, на которые нет зависимостей и которые никак 
не работают с железом (т.е. - не драйвера). По факту - всё что в Contrib.

> 2) как получить усмотрение мантейнера на пакеты, не входяшие в первый класс.

Было бы здорово увидеть это в новой среде сборки из git'а.

[devel] Системное /прикладное ПО was: Концепция политики разработки дистрибутивов ALT Linux

[Denis Medvedev]

Уважаемые разработчики!
А не ввести ли пакету при заливке в сизиф тэг: системное/прикладное программное обеспечение?
Ведь тогда можно будет отделить систему от, скажем, кучи игр и графических приложений?
И ясно будет, что прикладное ПО можно спокойно менять, не нарушая целостности системы.
   Денис Медведев nbr@

Re: [devel] Системное /прикладное ПО was: Концепция политики разработки дистрибутивов ALT Linux

[Шакиров Ленар]

В сообщении от Tuesday 29 July 2008 17:07:04 Denis Medvedev написал(а):
> Уважаемые разработчики!
> А не ввести ли пакету при заливке в сизиф тэг: системное/прикладное
> программное обеспечение? Ведь тогда можно будет отделить систему от,
> скажем, кучи игр и графических приложений? И ясно будет, что прикладное ПО
> можно спокойно менять, не нарушая целостности системы. Денис Медведев nbr@
> _______________________________________________

Может вместо тега юзать Group из спека?

С уважением, инженер отдела ИИС ООО «Центр»
Шакиров Ленар Наилевич
shakirov@cg.ru
(843) 533-88-14

Российская Федерация
Казань, ул. Зинина, 3а
420029, а/я 81

http://www.cg.ru/

Re: [devel] Системное /прикладное ПО was: Концепция политики разработки дистрибутивов ALT Linux

[Slava Semushin]

29 июля 2008 г. 20:07 пользователь Denis Medvedev <a_mdl / mail.ru> написал:
> Уважаемые разработчики!
> А не ввести ли пакету при заливке в сизиф тэг: системное/прикладное программное обеспечение?

Что за тег? Где он будет храниться и где использоваться?

> Ведь тогда можно будет отделить систему от, скажем, кучи игр и графических приложений?

Для этого можно использовать тег Group у RPM-пакета, например.

> И ясно будет, что прикладное ПО можно спокойно менять, не нарушая целостности системы.

Кому ясно? Кто его менять собирается? Есть ACL и чужой пакет, я
изменить не смогу, будь то хоть glibc, хоть vegastrike.


P.S. Денис, я не очень понимаю чего вы хотите и зачем это надо.


-- 
+ Slava Semushin | slava.semushin @ gmail.com
+ ALT Linux Team | php-coder @ altlinux.ru

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

[Андрей Черепанов]

29 июля 2008 Igor Vlasenko написал:
> On Tue, Jul 29, 2008 at 02:08:36PM +0400, Андрей Черепанов wrote:
> > 29 июля 2008 Igor Vlasenko написал:
> > > >> 2. (нынешнее состояние) ничего не выкладывать в бранчи
> > >
> > > Звучит как-то непонятно.
> > > Ведь сейчас же в бранчи можно выкладывать, и люди кладут...
> >
> > Речь шла про будущие бранчи. Идея в том, чтобы давать выкладывать, чтобы
> > это выкладывание не разломало всё.
>
> я бы конкретизировал эту идею.
> IMHO, в том, чтобы на время заморозить бранч,
> скажем, на месяц, перед релизом,
> и в это время принимать только magor bug/security fixes,
> нет ничего плохого.
>
> Главное, чтобы не забыть разморозить, чтобы после релиза
> его можно было сопровождать.
Как раз после разморозки возможны проблемы, которые мы имели с Desktop 4.0.3.
Если не закрыть, нет никаких гарантий, что обновление всё не разломает и что в 
следующем билде появятся новые баги.

Мне предложили годовой выпуск бранча и разделения на стабильный и нестабильные 
бранчи. Тогда проблемы нет - в стабильный бранч попадают обновления по 
безопасности, а в нестабильный - весь backport без гарантий качества.


-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

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

[Michael Shigorin]

On Mon, Jul 28, 2008 at 06:23:34PM +0700, Mikhail Gusarov wrote:
>  АЧ> На странице http://freesource.info/wiki/AltLinux/Branches/ReleasePolitic
> Зачем ещё одна страница? Уже есть одна.

Тем более криво названная -- переименовал в ReleasePolicy.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

[Michael Shigorin]

On Mon, Jul 28, 2008 at 06:34:05PM +0400, Alexey I. Froloff wrote:
> > > Меня больше интересует процесс "стабилизации".  Пакеты
> > > хочется всё-таки перекладывать, а не мучительно
> > > бэкпортировать...
> > Стабилизация == доступность только для security fix. И только
> > для них.
> Т.е. если Некая Хрень в данном бранче не работает или работает
> плохо, эта Хрень считается в этом бранче несуществующей?

Перевожу: ты ограничил изменения одними security fixes, а надо
ещё critical bug fixes.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

[Michael Shigorin]

On Tue, Jul 29, 2008 at 02:08:36PM +0400, Андрей Черепанов wrote:
> > >> 2. (нынешнее состояние) ничего не выкладывать в бранчи

Не сработает.

> > Звучит как-то непонятно.  Ведь сейчас же в бранчи можно
> > выкладывать, и люди кладут...
> Речь шла про будущие бранчи. Идея в том, чтобы давать
> выкладывать, чтобы это выкладывание не разломало всё.

Это глупость, а не идея.  Особенно странно такое от тебя слышать,
поскольку ты же и ведёшь S40 путём контролируемой дистилляции M40.

Так и следует делать -- отпочковывается testing, а из него
_управляемо_ перетаскивается в stable.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

[Michael Shigorin]

On Mon, Jul 28, 2008 at 06:12:02PM +0300, Igor Vlasenko wrote:
> Очень продвинутые пользователи собрали бы в backports
> (у меня времени нет это самому пробить, 
> но отсутствие backports/x86_64 - гвоздь в ботинке)

Ага, вот только руками совсем не справлюсь -- автоматизировать надо.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[devel] branches and backports

[Michael Shigorin]

On Mon, Jul 28, 2008 at 07:23:53PM +0300, Igor Vlasenko wrote:
> Что-то собираю и для себя, но поделиться не могу, поскольку
> ложить в updates чужие пакеты я, как "тварь дрожащая, права не
> имею"

Почему?  Если уверен, что только улучшил -- клади.

> Так мои усилия уходят в песок.  А ведь если бы появились 1-2
> активных бакпортера, backports ожили бы, туда бы потянулись еще
> люди.  и было бы широкого бэкпортирования, как раньше в master
> 2.0-2.4.

Да, у M40 довольно приличные шансы быть как M24.

С бэкпортами -- mea culpa, вот только incominger мне так и не
дали, поскольку опять чуточку подрихтовывали.

2 dottedmag: мож подсобишь после wiki?

> > Или же будем выпускать дистрибутивы на Сизифе, напрочь
> > игнорируя бранчи, которые будут служить непонятно чему.
> > Наверно, интеллектуальным играм мейнтейнеров, как сейчас 4.1.

Ну... есть мнение, что M41 -- это ещё одна точка в наборе шишек.
Главное из них выводы делать.

> 4.1 тоже был живой, пока не вышел rpm c lzma. 
> Было бы правильно, если бы его переложили в 4.1.

Ага.  Причём непонятно, почему это до сих пор не так -- видимо,
заинтересованные и могущие пользуются или M40, или Sisyphus.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

[Michael Shigorin]

On Tue, Jul 29, 2008 at 02:32:14PM +0400, Anton V. Boyarshinov wrote:
> > Может, ввести практику двух Incoming: в Сизиф и обобщённый
> > для всех бранчей. 
> Это как? Пакеты в разных бранчах могут иметь разыне
> зависимости, местами разный код и обязаны иметь разные релизы.

Ага, тут скорее авторелиз бы помог -- туда копали ab@, raorn@
и ваш покорный слуга, каждый раз обсуждение уходило в никуда.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

[Michael Shigorin]

On Tue, Jul 29, 2008 at 01:43:13PM +0300, Igor Vlasenko wrote:
> Предлагаю следующее 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/.
> (В этом пункте могу помочь)

IMHO лучше backports.altlinux.org/Mxx/ +/- как вариант --
в корень отображать текущие, а для прошлых воспользоваться
разработанным liks@ механизмом отслеживания веток.

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

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

За что??

> или сделать симлинками на 4.0/branch 4.1/branch)
> или внятно разъяснить, чем они отличаются от 4.0/branch 4.1/branch
> и какие там правила доступа.

Они как раз отличаются -- в updates переносится то, что критично
(IMHO хорошей меркой является "обновил бы я это по крону или нет").

Вот в incoming куча мала получилась -- вместо
/incoming/branch/4.x/ или там /incoming/4.x/ работает
/incoming/updates/4.x/ и это сбивает с толку, поскольку
результат попадает не в updates, а [сперва] в бранч.

Опять же лишний головняк на принимающей стороне -- это таки
нужный апдейт приехал или дежурное улучшение в бранче.

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

Автоматика соберёт, а вот пропустит ли keeper...

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

BTW это можно бы прикрутить к "личному кабинету" в sisyphus.ru,
если когда-либо у нас наконец будет сделано средство для
центрального хранения информации навроде "список участников 
команды в ldap с публичными ключами и подобным".

Типа галочек "я использую такие и такие репо".

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

IMHO это уже есть в рамках sisyphus.ru, только названия в пути
немного неудачные получились:

http://sisyphus.ru/srpm/apache/
http://sisyphus.ru/srpm/Sisyphus/apache/
http://sisyphus.ru/srpm/Daedalus/apache/
http://sisyphus.ru/srpm/Branch4/apache/
http://sisyphus.ru/srpm/UP4/apache/
http://sisyphus.ru/srpm/Branch3/apache/

Мож в какой packages.altlinux.org это всё получится свести?

/apache -- сводка по всем известным репо
/sisyphus/apache -- сизифный
/branch/4.0/apache -- ...
/updates/4.0/apache

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

[Michael Shigorin]

On Mon, Jul 28, 2008 at 06:38:07PM +0400, Андрей Черепанов wrote:
> > > Стабилизация == доступность только для security fix. И только для них.
> > Не вижу причин закрывать бранч для просто (не security)
> > fix'ов (без добавления новых фич)
> Ну тогда нет смысла выпускать качественные дистрибутивы на этом бранче.

Андрюш, ты перечитай, что написал-то.

Качественные -- это с "просто фиксами".  Безопасные --
это "с секьюрити фиксами".

Дальше пояснять или уже догадался?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[devel] M40/S40

[Michael Shigorin]

On Tue, Jul 29, 2008 at 12:06:56PM +0400, Anton V. Boyarshinov wrote:
> > в 4.0 было сделано продуманно:
> > по факту был сизиф, общий бранч, и (частично) бранч
> > дистрибутива.  И пакеты перекладывались по цепочке.
> > Из сизифа в бранч майнтайнерами, 
> > а из бранча брались в дистрибутив выпускающими.
> Последняя строчка неверна. Дистрибутивы собирались и собираются
> непосредственно из бранча

Только школьные и Руна сейчас -- никак из школьного,
который суть stable 4.0 (при M40 == testing)? ;-)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

[Андрей Черепанов]

30 июля 2008 Michael Shigorin написал:
> On Mon, Jul 28, 2008 at 06:38:07PM +0400, Андрей Черепанов wrote:
> > > > Стабилизация == доступность только для security fix. И только для
> > > > них.
> > >
> > > Не вижу причин закрывать бранч для просто (не security)
> > > fix'ов (без добавления новых фич)
> >
> > Ну тогда нет смысла выпускать качественные дистрибутивы на этом бранче.
>
> Андрюш, ты перечитай, что написал-то.
>
> Качественные -- это с "просто фиксами".  Безопасные --
> это "с секьюрити фиксами".
>
> Дальше пояснять или уже догадался?
Миша, просто фиксы без проверки QA и полноценного тестирования - это просто 
фиксы, к качеству практически не имеющие отношения. Сам догадаешься 
почему? ;)

-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

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

[Андрей Черепанов]

30 июля 2008 Michael Shigorin написал:
> On Tue, Jul 29, 2008 at 02:08:36PM +0400, Андрей Черепанов wrote:
> > > >> 2. (нынешнее состояние) ничего не выкладывать в бранчи
>
> Не сработает.
>
> > > Звучит как-то непонятно.  Ведь сейчас же в бранчи можно
> > > выкладывать, и люди кладут...
> >
> > Речь шла про будущие бранчи. Идея в том, чтобы давать
> > выкладывать, чтобы это выкладывание не разломало всё.
>
> Это глупость, а не идея.  Особенно странно такое от тебя слышать,
> поскольку ты же и ведёшь S40 путём контролируемой дистилляции M40.
Ты не путай школьные дистрибутивы и гражданские дистрибутивы с более широкой 
функциональностью.

> Так и следует делать -- отпочковывается testing, а из него
> _управляемо_ перетаскивается в stable.
Сейчас testing для школьного бранча закрыт. Возможно, если его открыть, то 
будет иметь смысл. Но если даже сотрудники ООО туда не постили, то что 
говорить про сторонних мейнтейнеров?


-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

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

[Андрей Черепанов]

30 июля 2008 Michael Shigorin написал:
> On Mon, Jul 28, 2008 at 06:34:05PM +0400, Alexey I. Froloff wrote:
> > > > Меня больше интересует процесс "стабилизации".  Пакеты
> > > > хочется всё-таки перекладывать, а не мучительно
> > > > бэкпортировать...
> > >
> > > Стабилизация == доступность только для security fix. И только
> > > для них.
> >
> > Т.е. если Некая Хрень в данном бранче не работает или работает
> > плохо, эта Хрень считается в этом бранче несуществующей?
>
> Перевожу: ты ограничил изменения одними security fixes, а надо
> ещё critical bug fixes.
Кто определяет что фикс является critical?


-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

[devel] QA and {sec "vs" crit} fixes

[Michael Shigorin]

On Wed, Jul 30, 2008 at 04:28:24PM +0400, Андрей Черепанов wrote:
> > > > > Стабилизация == доступность только для security fix. И
> > > > > только для них.
> > > > Не вижу причин закрывать бранч для просто (не security)
> > > > fix'ов (без добавления новых фич)
> > > Ну тогда нет смысла выпускать качественные дистрибутивы на этом бранче.
> > Андрюш, ты перечитай, что написал-то.
> > Качественные -- это с "просто фиксами".  Безопасные --
> > это "с секьюрити фиксами".
> > Дальше пояснять или уже догадался?
> Миша, просто фиксы без проверки QA и полноценного тестирования
> - это просто фиксы, к качеству практически не имеющие
> отношения.

Не драматизируй, без выделенного QA получились Junior 1.1,
Master 2.4 и Server 4.0.  Вполне достойные вещи -- благодаря
тому, что в их компонентах были заинтересованы майнтейнеры.

Это стоит ценить и не стоит сбрасывать со счётов таким вот
движением.  Просто майнтейнерам тоже не мешает помощь там,
где им или неинтересно, или некогда.  И вот тут действительно
незаменим выделенный человек или лучше команда QA.

> Сам догадаешься почему? ;)

Боюсь, ты слишком высокого мнения про QA, который может себе
позволить (и найти) ООО.  Хороший тестер -- редкий персонаж.
Собсно кому рассказывать буду-то. :-)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[devel] unstable, testing, stable...

[Michael Shigorin]

On Wed, Jul 30, 2008 at 04:37:13PM +0400, Андрей Черепанов wrote:
> > > > >> 2. (нынешнее состояние) ничего не выкладывать в бранчи
> > Не сработает.
> > > > Звучит как-то непонятно.  Ведь сейчас же в бранчи можно
> > > > выкладывать, и люди кладут...
> > > Речь шла про будущие бранчи. Идея в том, чтобы давать
> > > выкладывать, чтобы это выкладывание не разломало всё.
> > Это глупость, а не идея.  Особенно странно такое от тебя
> > слышать, поскольку ты же и ведёшь S40 путём контролируемой
> > дистилляции M40.
> Ты не путай школьные дистрибутивы и гражданские дистрибутивы с
> более широкой функциональностью.

Я про Руну-то к чему упомянул?  Что стихийно сложилось положение,
которое вообще-то было предсказуемым и к которому стоило идти
осмысленно.

> > Так и следует делать -- отпочковывается testing, а из него
> > _управляемо_ перетаскивается в stable.
> Сейчас testing для школьного бранча закрыт. Возможно, если его
> открыть, то будет иметь смысл. Но если даже сотрудники ООО туда
> не постили, то что говорить про сторонних мейнтейнеров?

Ну так сейчас мало кто вообще в курсе, что если найдена страшная 
бага, которая до сих пор не всплыла (или всплыла там, где и
понять-то не смогли, что стряслось) -- надо бы дёрнуть
майнтейнера стабильной ветки.

Если получится формализовать, то может выйти нечто вроде

Sisyphus(unstable) -> branch(testing) -> release(stable),
из которого для продуктов с повышенными требованиями можно
отмораживать ещё более жёстко проверяемые бранчи, если
понадобится.

Ну и чтоб путь прохождения пакетов был максимально удобен и
понятен, тогда и баги (в т.ч. безопасности) будут меньше жить.
Причём не только где-то в одном бранче.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[devel] errata

[Michael Shigorin]

On Wed, Jul 30, 2008 at 04:39:44PM +0400, Андрей Черепанов wrote:
> > > > Стабилизация == доступность только для security fix. И
> > > > только для них.
> > > Т.е. если Некая Хрень в данном бранче не работает или работает
> > > плохо, эта Хрень считается в этом бранче несуществующей?
> > Перевожу: ты ограничил изменения одними security fixes,
> > а надо ещё critical bug fixes.
> Кто определяет что фикс является critical?

Майнтейнер и QA.  Например, оправданная (по их мнению) важность
исправленной баги critical/blocker может быть характеристикой
critical bugfix.

Попросту говоря, если кто-нить вешает мне багу "recoll падает при
старте от нового пользователя", при этом он включен в тот же
школьный дистрибутив -- то ты как QA можешь решить поднять статус
до критического (поскольку такая бага не даёт возможности
пользоваться программой вообще), я как майнтейнер могу починить
и предложить в качестве critical bugfix в стабильные бранчи.

Это ничего нового, это всё сто лет в обед как известно -- почитай
редхатовские errata, например.  Или Диму спроси.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] unstable, testing, stable...

[Андрей Черепанов]

30 июля 2008 Michael Shigorin написал:
> Если получится формализовать, то может выйти нечто вроде
>
> Sisyphus(unstable) -> branch(testing) -> release(stable),
> из которого для продуктов с повышенными требованиями можно
> отмораживать ещё более жёстко проверяемые бранчи, если
> понадобится.
>
> Ну и чтоб путь прохождения пакетов был максимально удобен и
> понятен, тогда и баги (в т.ч. безопасности) будут меньше жить.
> Причём не только где-то в одном бранче.
Как раз упрощение размещения в бранч(и) как раз и является камнем преткновения 
при реализации этой идеи.

Как я понял, никто не возражает против схемы:
1. Есть Sisyphus
2. Есть testing branch - постят все желающие
3. Есть stable branch - попадают security fix и critical bug fix 
(перекладывают определённые люди после тестирования).

Срок жизни бранча - год?

-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

Re: [devel] unstable, testing, stable...

[Led]

В сообщении от Wednesday 30 July 2008 16:05:04 Андрей Черепанов написал(а):
> 30 июля 2008 Michael Shigorin написал:
> > Если получится формализовать, то может выйти нечто вроде
> >
> > Sisyphus(unstable) -> branch(testing) -> release(stable),
> > из которого для продуктов с повышенными требованиями можно
> > отмораживать ещё более жёстко проверяемые бранчи, если
> > понадобится.
> >
> > Ну и чтоб путь прохождения пакетов был максимально удобен и
> > понятен, тогда и баги (в т.ч. безопасности) будут меньше жить.
> > Причём не только где-то в одном бранче.
>
> Как раз упрощение размещения в бранч(и) как раз и является камнем
> преткновения при реализации этой идеи.
>
> Как я понял, никто не возражает против схемы:
> 1. Есть Sisyphus
> 2. Есть testing branch - постят все желающие
> 3. Есть stable branch - попадают security fix и critical bug fix
> (перекладывают определённые люди после тестирования).
>
> Срок жизни бранча - год?

ИМХО срок жизни - пока востребован.

-- 
Led

Re: [devel] unstable, testing, stable...

[Ivan Fedorov]

2008/7/30 Led <ledest@gmail.com>:
>> Срок жизни бранча - год?
>
> ИМХО срок жизни - пока востребован.
Это максимальный, а вот минимально гарантировать тоже что-то надо...
вопрос в том, кто будет давать эти самые гарантии... ООО? а оно ему
надо?..

Re: [devel] unstable, testing, stable...

[Andrii Dobrovol`s`kii]

[-- Attachment #1: Type: text/plain, Size: 1799 bytes --]

Led пишет:
> В сообщении от Wednesday 30 July 2008 16:05:04 Андрей Черепанов написал(а):
>> 30 июля 2008 Michael Shigorin написал:
>>> Если получится формализовать, то может выйти нечто вроде
>>>
>>> Sisyphus(unstable) -> branch(testing) -> release(stable),
>>> из которого для продуктов с повышенными требованиями можно
>>> отмораживать ещё более жёстко проверяемые бранчи, если
>>> понадобится.
>>>
>>> Ну и чтоб путь прохождения пакетов был максимально удобен и
>>> понятен, тогда и баги (в т.ч. безопасности) будут меньше жить.
>>> Причём не только где-то в одном бранче.
>> Как раз упрощение размещения в бранч(и) как раз и является камнем
>> преткновения при реализации этой идеи.
>>
>> Как я понял, никто не возражает против схемы:
>> 1. Есть Sisyphus
>> 2. Есть testing branch - постят все желающие
>> 3. Есть stable branch - попадают security fix и critical bug fix
>> (перекладывают определённые люди после тестирования).
>>
>> Срок жизни бранча - год?
> 
> ИМХО срок жизни - пока востребован.
> 
ИМХО, при бранчевании раз в пол-года -- нереально. Но, год маловато.
На мой взгляд, бранчевание дважды в год через чур часто. Лучше раз в
год но реально качественный бранч чем дважды непонятно что.
При этом срок жизни до появления третьего следующего бранча. Т.е. на
третий год в идеале поддержка прекращается. Иначе слишком
кавалерийский темп. Имеющимися силами выдержать его будет нереально.

-- 
Rgrds,
Andriy
*********************************************************************
email: dobr at iop dot kiev dot ua            Kyiv, Ukraine
Phone: (380-44)   525-7824            Department of Gas Electronics
Fax:   (380-44)   525-2329             Institute of Physics of NASU
*********************dobrATjabber.iop.kiev.ua************************


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] unstable, testing, stable...

[Michael Shigorin]

On Wed, Jul 30, 2008 at 05:05:04PM +0400, Андрей Черепанов wrote:
> Как я понял, никто не возражает против схемы:
> 1. Есть Sisyphus
> 2. Есть testing branch - постят все желающие
> 3. Есть stable branch - попадают security fix и critical bug fix 
> (перекладывают определённые люди после тестирования).

Меня устраивает.

> Срок жизни бранча - год?

Сложный вопрос.  Серверных и заказных явно может быть больше,
а промежуточные (вроде 4.1) могут жить дольше активно только 
при условии удобной миграции туда пакетов.  Т.е. или
перекладывание (что упирается в $BRANCH_MAINTAINER),
или удобное бэкпортирование.

Я бы для начала ориентировался на заявленные полгода,
потом смотрел по ресурсам и практике.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] unstable, testing, stable...

[Michael Shigorin]

On Wed, Jul 30, 2008 at 05:07:40PM +0300, Andrii Dobrovol`s`kii wrote:
> >> Срок жизни бранча - год?
> > ИМХО срок жизни - пока востребован.
> ИМХО, при бранчевании раз в пол-года -- нереально. Но, год
> маловато.  На мой взгляд, бранчевание дважды в год через чур
> часто. Лучше раз в год но реально качественный бранч чем дважды
> непонятно что.  При этом срок жизни до появления третьего
> следующего бранча. Т.е. на третий год в идеале поддержка
> прекращается. Иначе слишком кавалерийский темп. Имеющимися
> силами выдержать его будет нереально.

Мне вот тоже так кажется.

Это как пресса -- бывают ежедневные газеты с вечным дурдомом
и полным отсутствием памяти о том, что было вчера, а бывают
ежемесячные журналы.

Вот мне так кажется потому, что ALT больше похож на ежемесячный
журнал... и не уверен, что хочется дурдома газеты.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[devel] speak loudly [was: distro support TZ]

[Igor Vlasenko]

On Tue, Jul 29, 2008 at 03:13:23PM +0400, Anton V. Boyarshinov wrote:
> > поверить не могу.
> > Неужели "прямщас" могу взять и залить gcc или там glibc
> > в incoming/updates/4.0?
> > И автоматика меня пропустит?
> Залить можно. Автоматика -- пропустит. 

И эта военная тайна почти 2!!! года скрывалась 
от (внешних) майнтайнеров :(

В результате в 4.0 нет ряда обновлений,
которые я мог бы в свое время выложить, 
да не выложил, а теперь даже srpm найти не могу ;(

Господа, 
это лишний пример того, что не надо ничего держать 
в голове и/ли обсуждать усно в тесном кругу.
даже казалось бы всем известные вещи 
нуждаются в письменной фиксации!!!

О новых "всем известных" вещах нужно обязательно писать 
в @devel, а устоявшиеся традиции нужно записывать в 
полиси и howto.

-- 

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

Re: [devel] speak loudly [was: distro support TZ]

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1289 bytes --]

On Fri, Aug 01, 2008 at 12:18:24AM +0300, Igor Vlasenko wrote:
> On Tue, Jul 29, 2008 at 03:13:23PM +0400, Anton V. Boyarshinov wrote:
> > > поверить не могу.
> > > Неужели "прямщас" могу взять и залить gcc или там glibc
> > > в incoming/updates/4.0?
> > > И автоматика меня пропустит?
> > Залить можно. Автоматика -- пропустит. 
> 
> И эта военная тайна почти 2!!! года скрывалась 
> от (внешних) майнтайнеров :(

Какая вам разница, кто завернул пакет, робот или человек?

Я вообще имею дурную привычку отсматривать изменения некоторых пакетов,
отправленных в incoming/updates/4.0, вне зависимости от того, кто их туда
отправил.  А также изменения любых пакетов, отправленных туда некоторыми
мантейнерами.

Другой incominger может такой привычки не иметь.
Your mileage may vary.

> В результате в 4.0 нет ряда обновлений,
> которые я мог бы в свое время выложить, 
> да не выложил, а теперь даже srpm найти не могу ;(

Ну и зря.  За роботами стоят люди.
Я неоднократно пропускал пакеты в Сизиф, которые заворачивал робот по ACL.

> Господа, 
> это лишний пример того, что не надо ничего держать 
> в голове и/ли обсуждать усно в тесном кругу.
> даже казалось бы всем известные вещи 
> нуждаются в письменной фиксации!!!

Не надо, конечно.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Vladimir V. Kamarzin]

>>>>> On 30 Июл 2008 at 16:42 "MS" == Michael Shigorin writes:

>> > > Меня больше интересует процесс "стабилизации".  Пакеты
>> > > хочется всё-таки перекладывать, а не мучительно
>> > > бэкпортировать...
>> > Стабилизация == доступность только для security fix. И только
>> > для них.
>> Т.е. если Некая Хрень в данном бранче не работает или работает
>> плохо, эта Хрень считается в этом бранче несуществующей?

MS> Перевожу: ты ограничил изменения одними security fixes, а надо
MS> ещё critical bug fixes.

Меня очень интересует вопрос - что делать, если в программе выявлен critical
bug или security flaw, и в сизифе версия уже старше чем в бранче? Я не думаю,
что мы готовы бэкпортить все фиксы из новых версий в старые, как это делают в
debian.

Т.е. собственно вопрос: допускать ли обновление версии в бранче, если на то
есть веские причины типа серьёзных исправлений?

-- 
Mouse has out-of-cheese-error

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

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 270 bytes --]

Vladimir V. Kamarzin пишет:
...
> 
> Т.е. собственно вопрос: допускать ли обновление версии в бранче, если на то
> есть веские причины типа серьёзных исправлений?

  При возможности ничего не ломающего обновления -- допускать.

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]

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

[Igor Vlasenko]

On Fri, Aug 01, 2008 at 11:54:54AM +0400, Aleksey Avdeev wrote:
>   При возможности ничего не ломающего обновления -- допускать.
+1.

Обобщая, предлагаю схему Миши Шигорина==debian, но в наших
реалиях, как оно по сути и есть, только его нужно 
расставить по полочкам.

И так, дистрибутив X.Y:
к нему 3 репозитария:

1)
updates/X.Y - это то, что хочет уважаемый Андрей Черепанов <cas@>.
После стабилизации для бранча выпускаются только обновления по безопасности.

2)
branch/X.Y - это то, что хочет народ:
> Т.е. собственно вопрос: допускать ли обновление версии в бранче, если на то
> есть веские причины типа серьёзных исправлений?
При возможности ничего не ломающего обновления -- допускать.

3)
backports/X.Y - место для потенциально ломающих обюновлений.
При этом у меня есть RFC для следующего дополнения к backports полиси:

============== RFC ==================
Пакеты в backports в силу своей потенциальной нестабильности 
должны быть атомарно изолированы. 

Т.е. при попадании в incoming backports пакет должен сначала
собираться в окружении distro+branch, и только если попытка
сборки не удалась, то в  окружении distro+branch+backports.

В спорных ситуациях бакпортер всегда явно может затребовать
пакет из backports, явно указав foo >= ver.
=====================================

Обоснование: чтобы при обновлении из backports один нестабильный
пакет не тянул заведомо для него лишние другие нестабильные пакеты.


Осталось только принять такое полиси и явно развести инкоминги
для бранчей и updates (backports уже есть), чтобы легко было видно,
куда эта сборка позиционируется.

-- 

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

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

[Андрей Черепанов]

1 августа 2008 Igor Vlasenko написал:
> On Fri, Aug 01, 2008 at 11:54:54AM +0400, Aleksey Avdeev wrote:
> >   При возможности ничего не ломающего обновления -- допускать.
>
> +1.
>
> Обобщая, предлагаю схему Миши Шигорина==debian, но в наших
> реалиях, как оно по сути и есть, только его нужно
> расставить по полочкам.
>
> И так, дистрибутив X.Y:
> к нему 3 репозитария:
>
> 1)
> updates/X.Y - это то, что хочет уважаемый Андрей Черепанов <cas@>.
> После стабилизации для бранча выпускаются только обновления по
> безопасности.
>
> 2)
>
> branch/X.Y - это то, что хочет народ:
> > Т.е. собственно вопрос: допускать ли обновление версии в бранче, если на
> > то есть веские причины типа серьёзных исправлений?
>
> При возможности ничего не ломающего обновления -- допускать.
>
> 3)
> backports/X.Y - место для потенциально ломающих обюновлений.
А схема выкладывания такая: 
Sisyphus -> branch -> updates.
        |-> backports

?

-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

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

[Igor Vlasenko]

On Fri, Aug 01, 2008 at 12:43:05PM +0400, Андрей Черепанов wrote:
> А схема выкладывания такая: 
> Sisyphus -> branch -> updates.
>         |-> backports
> 
> ?

IMHO, 
схема
        |-> updates -> branch
Sisyphus -> branch --> updates.
        |-> backports
была бы удобнее.
Т.е. если, например, QA тим узнала на http://secunia.com
что foo < 0.9.37 с дыркой, а в бранче лежит
0.9.38 с фиксом, то она может его скопировать
по схеме branch --> updates.

Но если например майнтайнер знает, что в
дистрибутиве foo 3.47.3-alt1 заведомо не рабочий,
то он мог бы сразу залить foo 3.47.3-alt1.МX.Y.2 в
updates, откуда он автоматом при необходимости
(если нет пакета со старшим релизом) 
должен попасть и в бранч.

Обоснование:
Иначе майнтайнеру придется тратить доп. усилия
на оповещение QA 
(кстати, а механизма рабочий нигде и не прописан)
и их пинание, чтобы foo 3.47.3-alt1.МX.Y.2 попал
из бранча в updates.

Кроме того, желательно пакеты для updates собирать
не в бранче, а в более узком окружении
distro+updates.
Поэтому желательны разные инкоминги.

-- 

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

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

[Андрей Черепанов]

1 августа 2008 Igor Vlasenko написал:
> Т.е. если, например, QA тим узнала на http://secunia.com
> что foo < 0.9.37 с дыркой, а в бранче лежит
> 0.9.38 с фиксом, то она может его скопировать
> по схеме branch --> updates.
>
> Но если например майнтайнер знает, что в
> дистрибутиве foo 3.47.3-alt1 заведомо не рабочий,
> то он мог бы сразу залить foo 3.47.3-alt1.МX.Y.2 в
> updates, откуда он автоматом при необходимости
> (если нет пакета со старшим релизом)
> должен попасть и в бранч.
Получается, что непонятно, на чём делать качественные дистрибутивы. :(

--
Андрей Черепанов
ALT Linux
cas@altlinux.ru

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

[Igor Vlasenko]

On Fri, Aug 01, 2008 at 01:51:06PM +0400, Андрей Черепанов wrote:
> 1 августа 2008 Igor Vlasenko написал:
> > Т.е. если, например, QA тим узнала на http://secunia.com
> > что foo < 0.9.37 с дыркой, а в бранче лежит
> > 0.9.38 с фиксом, то она может его скопировать
> > по схеме branch --> updates.
> >
> > Но если например майнтайнер знает, что в
> > дистрибутиве foo 3.47.3-alt1 заведомо не рабочий,
> > то он мог бы сразу залить foo 3.47.3-alt1.МX.Y.2 в
> > updates, откуда он автоматом при необходимости
> > (если нет пакета со старшим релизом)
> > должен попасть и в бранч.
> Получается, что непонятно, на чём делать качественные дистрибутивы. :(

Почему? Разве это отличается от схемы
> Как я понял, никто не возражает против схемы:
> 1. Есть Sisyphus
> 2. Есть testing branch - постят все желающие
это branch
3. Есть stable branch - попадают security fix и critical bug fix
(перекладывают определённые люди после тестирования).
это updates

разница только в том, что я подчеркивал,
что инициатива о попадании в updates может исходить не только
от определённых людей, но и от майнтайнеров.

Последнее, IMHO, только хорошо.
Ведь есть майнтайнеры, которым все эти бранчи глубоко 
\ /
(=) по барабану.


-- 

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

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

[Андрей Черепанов]

1 августа 2008 Igor Vlasenko написал:
> On Fri, Aug 01, 2008 at 01:51:06PM +0400, Андрей Черепанов wrote:
> > 1 августа 2008 Igor Vlasenko написал:
> > > Т.е. если, например, QA тим узнала на http://secunia.com
> > > что foo < 0.9.37 с дыркой, а в бранче лежит
> > > 0.9.38 с фиксом, то она может его скопировать
> > > по схеме branch --> updates.
> > >
> > > Но если например майнтайнер знает, что в
> > > дистрибутиве foo 3.47.3-alt1 заведомо не рабочий,
> > > то он мог бы сразу залить foo 3.47.3-alt1.МX.Y.2 в
> > > updates, откуда он автоматом при необходимости
> > > (если нет пакета со старшим релизом)
> > > должен попасть и в бранч.
> >
> > Получается, что непонятно, на чём делать качественные дистрибутивы. :(
>
> Почему? Разве это отличается от схемы
>
> > Как я понял, никто не возражает против схемы:
> > 1. Есть Sisyphus
> > 2. Есть testing branch - постят все желающие
>
> это branch
> 3. Есть stable branch - попадают security fix и critical bug fix
> (перекладывают определённые люди после тестирования).
> это updates
>
> разница только в том, что я подчеркивал,
> что инициатива о попадании в updates может исходить не только
> от определённых людей, но и от майнтайнеров.
>
> Последнее, IMHO, только хорошо.
> Ведь есть майнтайнеры, которым все эти бранчи глубоко
> \ /
> (=) по барабану.
Просто налицо непонимание, что updates делается для бранча предыдущей версии. 
Нужно время возникновения updates. Он появляется как копия branch после 
стабилизации и выпуска дистрибутивов на его основе.

А так - возражений нет. Собственно, то, что обсуждали, к тому и пришло.

-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

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

[Igor Vlasenko]

On Fri, Aug 01, 2008 at 02:43:21PM +0400, Андрей Черепанов wrote:
> А так - возражений нет. Собственно, то, что обсуждали, к тому и пришло.

А что по техническим вопросам?
Я подчеркивал мысль, что проблемы с поддержкой во многом
порождены неудобной инфраструктурой.

Будут ли раздельные инкоминги для branch и updates?

Будут ли backports/4.0/x86_64 и backports/4.1/x86_64?

-- 

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

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

[Андрей Черепанов]

1 августа 2008 Igor Vlasenko написал:
> On Fri, Aug 01, 2008 at 02:43:21PM +0400, Андрей Черепанов wrote:
> > А так - возражений нет. Собственно, то, что обсуждали, к тому и пришло.
>
> А что по техническим вопросам?
> Я подчеркивал мысль, что проблемы с поддержкой во многом
> порождены неудобной инфраструктурой.
>
> Будут ли раздельные инкоминги для branch и updates?
>
> Будут ли backports/4.0/x86_64 и backports/4.1/x86_64?
Это уже ldv@ после отпуска ответит. Я за то, чтобы были.


-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

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

[Igor Vlasenko]

On Fri, Aug 01, 2008 at 03:18:26PM +0400, Андрей Черепанов wrote:
> > Будут ли backports/4.0/x86_64 и backports/4.1/x86_64?
> Это уже ldv@ после отпуска ответит. Я за то, чтобы были.

А как к такому предложению относитесь?
============== RFC ==================
Пакеты в backports в силу своей потенциальной нестабильности
должны быть атомарно изолированы.

Т.е. при попадании в incoming backports пакет должен сначала
собираться в окружении distro+branch, и только если попытка
сборки не удалась, то в  окружении distro+branch+backports.

В спорных ситуациях бакпортер всегда явно может затребовать
пакет из backports, явно указав foo >= ver.
=====================================

-- 

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

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

[Андрей Черепанов]

1 августа 2008 Igor Vlasenko написал:
> On Fri, Aug 01, 2008 at 03:18:26PM +0400, Андрей Черепанов wrote:
> > > Будут ли backports/4.0/x86_64 и backports/4.1/x86_64?
> >
> > Это уже ldv@ после отпуска ответит. Я за то, чтобы были.
>
> А как к такому предложению относитесь?
> ============== RFC ==================
> Пакеты в backports в силу своей потенциальной нестабильности
> должны быть атомарно изолированы.
>
> Т.е. при попадании в incoming backports пакет должен сначала
> собираться в окружении distro+branch, и только если попытка
> сборки не удалась, то в  окружении distro+branch+backports.
>
> В спорных ситуациях бакпортер всегда явно может затребовать
> пакет из backports, явно указав foo >= ver.
> =====================================
Полностью согласен.


-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

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

[Led]

В сообщении от Friday 01 August 2008 13:57:46 Igor Vlasenko написал(а):
> On Fri, Aug 01, 2008 at 02:43:21PM +0400, Андрей Черепанов wrote:
> > А так - возражений нет. Собственно, то, что обсуждали, к тому и пришло.
>
> А что по техническим вопросам?
> Я подчеркивал мысль, что проблемы с поддержкой во многом
> порождены неудобной инфраструктурой.
>
> Будут ли раздельные инкоминги для branch и updates?

Тут всё время кивают на Debian. Но в Debian есть "updates" и "security 
updates", и это не одно и то же! Почему у нас пытаются свести "updates" 
к "security updates only"?

-- 
Led

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

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 489 bytes --]

Twas brillig at 15:29:26 01.08.2008 UTC+03 when ledest@gmail.com did gyre and gimble:

 L> Тут всё время кивают на Debian. Но в Debian есть "updates" и
 L> "security updates", и это не одно и то же!

Updates там только до выпуска stable и являются средством работы над
testing во время приготовления stable.

После релиза - только security updates.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

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

[Андрей Черепанов]

1 августа 2008 Led написал:
> В сообщении от Friday 01 August 2008 13:57:46 Igor Vlasenko написал(а):
> > On Fri, Aug 01, 2008 at 02:43:21PM +0400, Андрей Черепанов wrote:
> > > А так - возражений нет. Собственно, то, что обсуждали, к тому и пришло.
> >
> > А что по техническим вопросам?
> > Я подчеркивал мысль, что проблемы с поддержкой во многом
> > порождены неудобной инфраструктурой.
> >
> > Будут ли раздельные инкоминги для branch и updates?
>
> Тут всё время кивают на Debian. Но в Debian есть "updates" и "security
> updates", и это не одно и то же! Почему у нас пытаются свести "updates"
> к "security updates only"?
Уже пришли к выводу, что отдельных апдейтов по безопасности не будет. Будут 
обновления по безопасности и критическим багам в одном месте.



-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

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

[Led]

В сообщении от Friday 01 August 2008 15:36:59 Андрей Черепанов написал(а):
> 1 августа 2008 Led написал:
> > В сообщении от Friday 01 August 2008 13:57:46 Igor Vlasenko написал(а):
> > > On Fri, Aug 01, 2008 at 02:43:21PM +0400, Андрей Черепанов wrote:
> > > > А так - возражений нет. Собственно, то, что обсуждали, к тому и
> > > > пришло.
> > >
> > > А что по техническим вопросам?
> > > Я подчеркивал мысль, что проблемы с поддержкой во многом
> > > порождены неудобной инфраструктурой.
> > >
> > > Будут ли раздельные инкоминги для branch и updates?
> >
> > Тут всё время кивают на Debian. Но в Debian есть "updates" и "security
> > updates", и это не одно и то же! Почему у нас пытаются свести "updates"
> > к "security updates only"?
>
> Уже пришли к выводу, что отдельных апдейтов по безопасности не будет. Будут
> обновления по безопасности и критическим багам в одном месте.

Ок. Тогда прошу прощения - видно я пропустил тот момент, когда пришли к такому 
выводу:)

-- 
Led

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

[Led]

В сообщении от Friday 01 August 2008 15:30:53 Mikhail Gusarov написал(а):
> Twas brillig at 15:29:26 01.08.2008 UTC+03 when ledest@gmail.com did gyre
> and gimble:
>
>  L> Тут всё время кивают на Debian. Но в Debian есть "updates" и
>  L> "security updates", и это не одно и то же!
>
> Updates там только до выпуска stable и являются средством работы над
> testing во время приготовления stable.

У нас тоже branch будет доводиться до состояния stable (в Debian'овском 
понимании)? Сколько времени на это будет отводиться? месяц? полгода?:)

>
> После релиза - только security updates.



-- 
Led

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

[Андрей Черепанов]

1 августа 2008 Led написал:
> В сообщении от Friday 01 August 2008 15:30:53 Mikhail Gusarov написал(а):
> > Twas brillig at 15:29:26 01.08.2008 UTC+03 when ledest@gmail.com did gyre
> > and gimble:
> >
> >  L> Тут всё время кивают на Debian. Но в Debian есть "updates" и
> >  L> "security updates", и это не одно и то же!
> >
> > Updates там только до выпуска stable и являются средством работы над
> > testing во время приготовления stable.
>
> У нас тоже branch будет доводиться до состояния stable (в Debian'овском
> понимании)? Сколько времени на это будет отводиться? месяц? полгода?:)
Срок жизни бранча - полгода. За месяц до стабилизации он будет доводится до 
стабильного состояния. После этого бранч доступен только для исправлений 
критичных багов и безопасности.


-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

[devel] backports/64

[Michael Shigorin]

On Fri, Aug 01, 2008 at 01:57:46PM +0300, Igor Vlasenko wrote:
> Будут ли backports/4.0/x86_64 и backports/4.1/x86_64?

Это зависит, например, от нас с тобой ;-)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] backports/64

[Igor Vlasenko]

On Tue, Aug 05, 2008 at 03:11:58PM +0300, Michael Shigorin wrote:
> On Fri, Aug 01, 2008 at 01:57:46PM +0300, Igor Vlasenko wrote:
> > Будут ли backports/4.0/x86_64 и backports/4.1/x86_64?
> 
> Это зависит, например, от нас с тобой ;-)

$ ls /var/ftp/pub/Linux/jpackage/5.0/generic/free/SRPMS | wc -l
336
Пока не пробьюсь сквозь эти 336 спартанцев,
не смогу физически :(

-- 

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