[devel] Бранчи и прочее

[devel] Бранчи и прочее

[Eugene Ostapets]

Попытаюсь выразить свое более связно видение бранчей, близкое к
теперешним техническим возможностям git.alt, при реализации которого,
я безусловно буду заинтересован в работе над такими бранчами:

1. Карманы сложны для раелизации, но можно предоставить более-менее
публичное место для технологических экспериментов, такой себе
experimental (Daedalus из ныне живущих), со следующими свойствами:
а) нет acl (вообще нет!!!)
б) допускается публикация исключительно из git
в) проверяется наследование истории по git
г) публикация пакета другим мантейнером возможна только через какой-то
промежуток времени (мне кажется 5 дней достаточно)
д) анметы в данном репозитарии допускаются

2. unstable (Sisyphus) живет по нынешним законам, при условии, что
любые бомбы аля новый gcc, с которым несоберется N пакетов, но я его
вам не покажу до публикации в Сизифе, а вы попробуйте все сами
починить, минимум две недели отлеживаются в experimental

3. testing (5.0) самая интересная и самая сложная часть проекта:
а) acl на все пакеты на старте принадлежит двум группам: rm-5.0 и qa-alt
б) состав rm-5.0 должен избираться членами тим (допускается
самовыдвижение с программой партии :))
в) после определения целей данного бранча, определяется зона пакетов
main, где не допускаются API/ABI изменения, на остальные пакеты в этот
момент могут быть выставлены права nobody или everybody
г) прохождение пакетов в main требует подтверждения кого-то из rm-5.0
(да, даже для членов qa-alt, у которых может возникнуть конфликт
интересов с сообществом)

4. backports подчиняется тем же правилам, что и experimental, за
исключением того, что анметы возможны только в пакетах testing, а не в
пакетах backports.

PS: Я понимаю, что нужно выписать и устаканить полиси прохождения
пакета по цепочке experimental->unstable->testing(или backports), но
без предсказуемости жизненного цикла бранча, он разработчикам будет
по-прежнему не интересен.
PPS: я намерено исключил из этой схемы бранч p5 - ООО само решит из
каких бранчей какие пакеты стоит брать.

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] Бранчи и прочее

[Eugene Prokopiev]

7 сентября 2009 г. 8:55 пользователь Eugene Ostapets
(eostapets@gmail.com) написал:
> Попытаюсь выразить свое более связно видение бранчей, близкое к
> теперешним техническим возможностям git.alt, при реализации которого,
> я безусловно буду заинтересован в работе над такими бранчами:

<skip>

Покажите мне тех, кто не будет заинтересован :) Все это чудесно, но
это прожекты в духе моего варианта (1), который требует отсутствующих
в настоящее время ресурсов :( Я был бы рад ошибиться ...

-- 
С уважением,
Прокопьев Евгений

Re: [devel] Бранчи и прочее

[Eugene Ostapets]

2009/9/7 Eugene Prokopiev <enp altlinux.org>:
> 7 сентября 2009 г. 8:55 пользователь Eugene Ostapets
> (eostapets@gmail.com) написал:
>> Попытаюсь выразить свое более связно видение бранчей, близкое к
>> теперешним техническим возможностям git.alt, при реализации которого,
>> я безусловно буду заинтересован в работе над такими бранчами:
>
> <skip>
>
> Покажите мне тех, кто не будет заинтересован :) Все это чудесно, но
> это прожекты в духе моего варианта (1), который требует отсутствующих
> в настоящее время ресурсов :( Я был бы рад ошибиться ...
Хм... Разве в отквоченной фразе не видно, что я готов РАБОТАТЬ над
таким бранчем, а не только пользоваться им?


-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] Бранчи и прочее

[Eugene Prokopiev]

> Хм... Разве в отквоченной фразе не видно, что я готов РАБОТАТЬ над
> таким бранчем, а не только пользоваться им?

Видно. Сколько еще готовых? Именно в отношении их количества я рад бы
ошибиться.

Да, я не готов работать над main.

-- 
С уважением,
Прокопьев Евгений

Re: [devel] Бранчи и прочее

[Eugene Ostapets]

2009/9/7 Eugene Prokopiev <enp altlinux.org>:
>> Хм... Разве в отквоченной фразе не видно, что я готов РАБОТАТЬ над
>> таким бранчем, а не только пользоваться им?
>
> Видно. Сколько еще готовых? Именно в отношении их количества я рад бы
> ошибиться.
Прежде чем искать готовых, нужно определиться с правилами игры...
Я, на пример, не готов даже смотреть на бранч со свободной заливкой
чего угодно...

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] Бранчи и прочее

[REAL]

Eugene Prokopiev пишет:
>> Хм... Разве в отквоченной фразе не видно, что я готов РАБОТАТЬ над
>> таким бранчем, а не только пользоваться им?
> Видно. Сколько еще готовых? Именно в отношении их количества я рад бы
> ошибиться.

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

> Да, я не готов работать над main.

Смотря что подразумевать под работой. Простой перенос - думаю, не так 
сложен, проблема только в бутстрапах, вот по ним бы информация не 
помешала (я в прошлом году пробовал дома пересобирать gcc, ни одна 
попытка не удалась). Ну и вообще, где-то бы место иметь для пробных 
сборок, потому что у меня вот на etersoft есть контейнер x86_64, но он 
на сизифе. А самому переходить на такой бранч вообще-то не хочется, 
тогда утратится возможность полноценно работать над пакетами в сизифе.

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] Бранчи и прочее

[Eugene Prokopiev]

7 сентября 2009 г. 10:09 пользователь REAL (root@mmedia2.kemsu.ru) написал:

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

Напоминаю, 2 варианта:

1) есть люди, которые в состоянии взять на себя ответственность по
переносу/пересборке main откуда угодно (хоть из Сизифа, хоть из p5) -
и я не против премодерации этого main, если найдется кому этим
заниматься
2) таких людей нет, мейнтейнеры community-бранча по умолчанию
делегируют эту функцию мейнтейнеру p5, вмешиваясь только в случае
несогласия с переносом

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

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

>> Да, я не готов работать над main.
>
> Смотря что подразумевать под работой. Простой перенос - думаю, не так
> сложен, проблема только в бутстрапах, вот по ним бы информация не помешала
> (я в прошлом году пробовал дома пересобирать gcc, ни одна попытка не
> удалась).

Нет, даже API/ABI менять нежелательно (в main нельзя?), не говоря уже
о смене тулчейна

> Ну и вообще, где-то бы место иметь для пробных сборок, потому что
> у меня вот на etersoft есть контейнер x86_64, но он на сизифе. А самому
> переходить на такой бранч вообще-то не хочется, тогда утратится возможность
> полноценно работать над пакетами в сизифе.

Кто мешает указать хашеру целевой репозитарий, на котором и и для
которого производится сборка?

-- 
С уважением,
Прокопьев Евгений

Re: [devel] Бранчи и прочее

[Eugene Ostapets]

2009/9/7 REAL <root mmedia2.kemsu.ru>:
> Eugene Prokopiev пишет:
>>>
>>> Хм... Разве в отквоченной фразе не видно, что я готов РАБОТАТЬ над
>>> таким бранчем, а не только пользоваться им?
>>
>> Видно. Сколько еще готовых? Именно в отношении их количества я рад бы
>> ошибиться.
>
> Понятно, что основное - это перенос пакетов
> из сизифа (или уже договорились переносить из премодерируемого бранча?),
> непонятно, по каким принципам определять, что пакеты к этому уже готовы.
Если пакет закрывает одну или несколько баг и не порождает новых - он
кандидат на рассмотрение, иначе ему место в unstable

> И
> совсем непонятно, что делать с пакетами, мейнтейнеры которых в бранч
> портировать не будут, а на портирование другими лицами будут возмущаться.
Мнение мантейнеров репозитария unstable для релиз-менеджеров является
совещательным, т.е. возмущения в /dev/null


-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] Бранчи и прочее

[Aleksey Novodvorsky]

7 сентября 2009 г. 8:55 пользователь Eugene Ostapets
(eostapets@gmail.com) написал:
> Попытаюсь выразить свое более связно видение бранчей, близкое к
> теперешним техническим возможностям git.alt, при реализации которого,
> я безусловно буду заинтересован в работе над такими бранчами:
>
> 1. Карманы сложны для раелизации, но можно предоставить более-менее
> публичное место для технологических экспериментов, такой себе
> experimental (Daedalus из ныне живущих), со следующими свойствами:
> а) нет acl (вообще нет!!!)
> б) допускается публикация исключительно из git
> в) проверяется наследование истории по git
> г) публикация пакета другим мантейнером возможна только через какой-то
> промежуток времени (мне кажется 5 дней достаточно)
> д) анметы в данном репозитарии допускаются
>
> 2. unstable (Sisyphus) живет по нынешним законам, при условии, что
> любые бомбы аля новый gcc, с которым несоберется N пакетов, но я его
> вам не покажу до публикации в Сизифе, а вы попробуйте все сами
> починить, минимум две недели отлеживаются в experimental

Это, насколько я понимаю, отдельная часть предложения. Здесь у меня
одно замечание : за две недели возможно разъезжание experimental с
unstable. Проблема порождения новой сущности. То есть можно не
облегчить положение, а усугубить.

>
> 3. testing (5.0) самая интересная и самая сложная часть проекта:
> а) acl на все пакеты на старте принадлежит двум группам: rm-5.0 и qa-alt
> б) состав rm-5.0 должен избираться членами тим (допускается
> самовыдвижение с программой партии :))
> в) после определения целей данного бранча, определяется зона пакетов
> main, где не допускаются API/ABI изменения, на остальные пакеты в этот
> момент могут быть выставлены права nobody или everybody
> г) прохождение пакетов в main требует подтверждения кого-то из rm-5.0
> (да, даже для членов qa-alt, у которых может возникнуть конфликт
> интересов с сообществом)

Не вижу здесь никаких принципиальных проблем, кроме утрясания полиси.

>
> 4. backports подчиняется тем же правилам, что и experimental, за
> исключением того, что анметы возможны только в пакетах testing, а не в
> пакетах backports.

Не наоборот? Я не понимаю, зачем нужен backports. Мне кажется, что
судьба его будет печальна.

Rgrds, Алексей

>
> PS: Я понимаю, что нужно выписать и устаканить полиси прохождения
> пакета по цепочке experimental->unstable->testing(или backports), но
> без предсказуемости жизненного цикла бранча, он разработчикам будет
> по-прежнему не интересен.
> PPS: я намерено исключил из этой схемы бранч p5 - ООО само решит из
> каких бранчей какие пакеты стоит брать.
>
> --
> С уважением,
> Евгений Остапец
> uin: 23747217
> jid: eugene_ostapets@jabber.ru
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] Бранчи и прочее

[Eugene Ostapets]

2009/9/7 Aleksey Novodvorsky <aen altlinux.ru>:
> 7 сентября 2009 г. 8:55 пользователь Eugene Ostapets
> (eostapets@gmail.com) написал:
>> 2. unstable (Sisyphus) живет по нынешним законам, при условии, что
>> любые бомбы аля новый gcc, с которым несоберется N пакетов, но я его
>> вам не покажу до публикации в Сизифе, а вы попробуйте все сами
>> починить, минимум две недели отлеживаются в experimental
>
> Это, насколько я понимаю, отдельная часть предложения. Здесь у меня
> одно замечание : за две недели возможно разъезжание experimental с
> unstable. Проблема порождения новой сущности. То есть можно не
> облегчить положение, а усугубить.
Задача experimental именно утрясти сложные взаимосвязи не только на
уровне сборки (shared task), но и на уровне работоспособности не
дожидаясь появления карманов. Без этого полем для экспериментов
становится unstable, а это не его задача.
>> 4. backports подчиняется тем же правилам, что и experimental, за
>> исключением того, что анметы возможны только в пакетах testing, а не в
>> пакетах backports.
>
> Не наоборот? Я не понимаю, зачем нужен backports. Мне кажется, что
> судьба его будет печальна.
Пример: всегда найдется желающий собрать свежий kde4 для старого
бранча, репозитарий должен безпроблемно позволять установить этот
kde4, но обязательно при объединении породит анметы, потому что список
собранного с этим kde4, будет значительно меньше, чем собрано в
бранче. Пока что у нас нет ни полиси на backports, ни инфраструктуры
для него... Я верю, что он будет живым, потому что у меня перед
глазами примеры Debian/Suse/Redhat, не понимаю, почему нам бэкпорты
нужны меньше, чем им?

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] Бранчи и прочее

[REAL]

Eugene Prokopiev пишет:
> Напоминаю, 2 варианта:
> 
> 1) есть люди, которые в состоянии взять на себя ответственность по
> переносу/пересборке main откуда угодно (хоть из Сизифа, хоть из p5) -
> и я не против премодерации этого main, если найдется кому этим
> заниматься

Этот вариант неплох, вопрос в том, кто займётся. Здесь можно было бы 
даже отдать предпочтение p5, наверно.

> 2) таких людей нет, мейнтейнеры community-бранча по умолчанию
> делегируют эту функцию мейнтейнеру p5, вмешиваясь только в случае
> несогласия с переносом

А захочет ли он (мейнтейнер p5) этим заниматься?

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

Тоже вариант.

> Нет, даже API/ABI менять нежелательно (в main нельзя?), не говоря уже
> о смене тулчейна

Пожалуй, соглашусь. Только тогда нужно изначально чётко очертить 
границы main с какими-то возможностями двигания этих границ (скажем, 
необходимо обновить что-то не общесистемное, но требующее по 
зависимостям обновления/пересборки ряда других пакетов). Ну и потом не 
каждую смену API сборочница способна выловить, тут тоже что-то 
прописать в правилах не помешало бы.

>> Ну и вообще, где-то бы место иметь для пробных сборок, потому что
>> у меня вот на etersoft есть контейнер x86_64, но он на сизифе. А самому
>> переходить на такой бранч вообще-то не хочется, тогда утратится возможность
>> полноценно работать над пакетами в сизифе.
> Кто мешает указать хашеру целевой репозитарий, на котором и и для
> которого производится сборка?

В контейнере - наверно, можно будет обговорить с lav@ (когда возникнет 
необходимость, если всё же дойдёт дело до дела, а не закончится 
беседой), а вот дома это нереально: трафик.

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] Бранчи и прочее

[Денис Смирнов]

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

On Mon, Sep 07, 2009 at 10:23:53AM +0400, Aleksey Novodvorsky wrote:
 
AN> Это, насколько я понимаю, отдельная часть предложения. Здесь у меня
AN> одно замечание : за две недели возможно разъезжание experimental с
AN> unstable. Проблема порождения новой сущности. То есть можно не
AN> облегчить положение, а усугубить.

Мне кажется разъезжание не страшным, в случае если проходящие в Сизиф
пакеты с версией > чем в experimental будут автоматически замещать пакеты
в experimental.

>> 3. testing (5.0) самая интересная и самая сложная часть проекта:
>> а) acl на все пакеты на старте принадлежит двум группам: rm-5.0 и qa-alt
>> б) состав rm-5.0 должен избираться членами тим (допускается
>> самовыдвижение с программой партии :))
>> в) после определения целей данного бранча, определяется зона пакетов
>> main, где не допускаются API/ABI изменения, на остальные пакеты в этот
>> момент могут быть выставлены права nobody или everybody
>> г) прохождение пакетов в main требует подтверждения кого-то из rm-5.0
>> (да, даже для членов qa-alt, у которых может возникнуть конфликт
>> интересов с сообществом)
AN> Не вижу здесь никаких принципиальных проблем, кроме утрясания полиси.

Честно говоря мне не нравится идея мешать в кучу понятие 'testing' и
понятие 'release branch'.

AN> Не наоборот? Я не понимаю, зачем нужен backports. Мне кажется, что
AN> судьба его будет печальна.

Для backports есть одно важное применение -- разруливание конфликтов вроде
того, что я озвучивал ранее с zaptel/dahdi. Или, к примеру, задача вроде
'хочу postgresql8.3 в 4.0'.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] Бранчи и прочее

[Led]

On Monday, 07 September 2009 07:55:25 Eugene Ostapets wrote:
> Попытаюсь выразить свое более связно видение бранчей, близкое к
> теперешним техническим возможностям git.alt, при реализации которого,
> я безусловно буду заинтересован в работе над такими бранчами:
>
> 1. Карманы сложны для раелизации, но можно предоставить более-менее
> публичное место для технологических экспериментов, такой себе
> experimental (Daedalus из ныне живущих), со следующими свойствами:
> а) нет acl (вообще нет!!!)
> б) допускается публикация исключительно из git

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

> в) проверяется наследование истории по git
> г) публикация пакета другим мантейнером возможна только через какой-то
> промежуток времени (мне кажется 5 дней достаточно)
> д) анметы в данном репозитарии допускаются

-- 
Led

Re: [devel] Бранчи и прочее

[Eugene Ostapets]

2009/9/7 Led <ledest gmail.com>:
> On Monday, 07 September 2009 07:55:25 Eugene Ostapets wrote:
>> Попытаюсь выразить свое более связно видение бранчей, близкое к
>> теперешним техническим возможностям git.alt, при реализации которого,
>> я безусловно буду заинтересован в работе над такими бранчами:
>>
>> 1. Карманы сложны для раелизации, но можно предоставить более-менее
>> публичное место для технологических экспериментов, такой себе
>> experimental (Daedalus из ныне живущих), со следующими свойствами:
>> а) нет acl (вообще нет!!!)
>> б) допускается публикация исключительно из git
>
> С этим не могу согласиться. Встречаются настолько кривые git-репозитарии, что
> проще сделать их заново, чем тащить к себе подобное ...
Тут предложение не о наследовании, а о работе исключительно из git,
учитывая статус экспериментальности, можно именно тут поправить чужие
"кривульки" и предложить мантейнеру в unstable взять "прямой" гит, а
собственную историю подшить через -s ours для прохождения теста на
преемственность. В рамках этого репозитария можно подготовить git для
тех компонент, мантейнеры которых вообще боятся браться за git и т.п.
Это поле для экпериментов.


-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] Бранчи и прочее

[Michael Pozhidaev]

Hello, Денис Смирнов!

> On Mon, Sep 07, 2009 at 10:23:53AM +0400, Aleksey Novodvorsky wrote:
>  
> AN> Это, насколько я понимаю, отдельная часть предложения. Здесь у меня
> AN> одно замечание : за две недели возможно разъезжание experimental с
> AN> unstable. Проблема порождения новой сущности. То есть можно не
> AN> облегчить положение, а усугубить.
>
> Мне кажется разъезжание не страшным, в случае если проходящие в Сизиф
> пакеты с версией > чем в experimental будут автоматически замещать пакеты
> в experimental.
+1
-- 
Michael Pozhidaev. E-mail: msp@altlinux.ru.
Tomsk State University. http://www.csd.tsu.ru
ALT Linux Team. http://www.altlinux.org

Re: [devel] Бранчи и прочее

[Aleksey Novodvorsky]

7 сентября 2009 г. 12:07 пользователь Денис Смирнов
(mithraen@altlinux.ru) написал:
> On Mon, Sep 07, 2009 at 10:23:53AM +0400, Aleksey Novodvorsky wrote:
>
> AN> Это, насколько я понимаю, отдельная часть предложения. Здесь у меня
> AN> одно замечание : за две недели возможно разъезжание experimental с
> AN> unstable. Проблема порождения новой сущности. То есть можно не
> AN> облегчить положение, а усугубить.
>
> Мне кажется разъезжание не страшным, в случае если проходящие в Сизиф
> пакеты с версией > чем в experimental будут автоматически замещать пакеты
> в experimental.

Это приведет к старению Сизифа. Мне кажется, что это плохое предложение.

Rgrds, Алексей

Re: [devel] Бранчи и прочее

[Денис Смирнов]

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

On Mon, Sep 07, 2009 at 09:19:39PM +0400, Aleksey Novodvorsky wrote:

>> Мне кажется разъезжание не страшным, в случае если проходящие в Сизиф
>> пакеты с версией > чем в experimental будут автоматически замещать пакеты
>> в experimental.
AN> Это приведет к старению Сизифа. Мне кажется, что это плохое предложение.

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

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] Бранчи и прочее

[Eugene Ostapets]

2009/9/7 Aleksey Novodvorsky <aen altlinux.ru>:
> 7 сентября 2009 г. 12:07 пользователь Денис Смирнов
> (mithraen@altlinux.ru) написал:
>> On Mon, Sep 07, 2009 at 10:23:53AM +0400, Aleksey Novodvorsky wrote:
>>
>> AN> Это, насколько я понимаю, отдельная часть предложения. Здесь у меня
>> AN> одно замечание : за две недели возможно разъезжание experimental с
>> AN> unstable. Проблема порождения новой сущности. То есть можно не
>> AN> облегчить положение, а усугубить.
>>
>> Мне кажется разъезжание не страшным, в случае если проходящие в Сизиф
>> пакеты с версией > чем в experimental будут автоматически замещать пакеты
>> в experimental.
>
> Это приведет к старению Сизифа. Мне кажется, что это плохое предложение.
Сизиф и так стремительно стареет из-за жестких ограничений и проверок
на входе. Увидеть python2.6 практически нереально, если у нас не
заведется Геракл... Или не родятся карманы, или... Фантазировать о
том, что и когда сможет оживить Сизиф можно долго... Статус
experimental с вытекающими из этого послаблений для Дедала могут
помочь(а могут и не помочь) оживить обновление пакетной базы для
Сизифа.

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] Бранчи и прочее

[Dmitry V. Levin]

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

On Mon, Sep 07, 2009 at 07:55:25AM +0300, Eugene Ostapets wrote:
> Попытаюсь выразить свое более связно видение бранчей, близкое к
> теперешним техническим возможностям git.alt, при реализации которого,
> я безусловно буду заинтересован в работе над такими бранчами:
> 
> 1. Карманы сложны для раелизации, но можно предоставить более-менее
> публичное место для технологических экспериментов, такой себе
> experimental (Daedalus из ныне живущих), со следующими свойствами:
> а) нет acl (вообще нет!!!)
> б) допускается публикация исключительно из git
> в) проверяется наследование истории по git
> г) публикация пакета другим мантейнером возможна только через какой-то
> промежуток времени (мне кажется 5 дней достаточно)
> д) анметы в данном репозитарии допускаются

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


-- 
ldv

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

Re: [devel] Бранчи и прочее

[Eugene Ostapets]

2009/9/8 Dmitry V. Levin <ldv altlinux.org>:
> On Mon, Sep 07, 2009 at 07:55:25AM +0300, Eugene Ostapets wrote:
>> Попытаюсь выразить свое более связно видение бранчей, близкое к
>> теперешним техническим возможностям git.alt, при реализации которого,
>> я безусловно буду заинтересован в работе над такими бранчами:
>>
>> 1. Карманы сложны для раелизации, но можно предоставить более-менее
>> публичное место для технологических экспериментов, такой себе
>> experimental (Daedalus из ныне живущих), со следующими свойствами:
>> а) нет acl (вообще нет!!!)
>> б) допускается публикация исключительно из git
>> в) проверяется наследование истории по git
>> г) публикация пакета другим мантейнером возможна только через какой-то
>> промежуток времени (мне кажется 5 дней достаточно)
>> д) анметы в данном репозитарии допускаются
>
> Похоже на описание разновидности кармана, с той существенной разницей, что
> он единый и обязательный для всех.  Для полноты картины нужно описать
> жизненный цикл одного пакета в этом кармане.
Он обязательный по полиси, но не технологически.
Рассмотрим пример python2.6:
Он мне нужен, но не настолько, чтобы пилить его в приватном бранче, но
я готов уделить ему некоторое время в публичном месте. На текущей
технологической площадке это может быть только огромный shared task,
на битву с которым у меня нет ни сил, ни времени. Допустим набралась
критическая масса джедаев на такой таск, ценой нескольких недель, если
не месяцев, пропихнули его в Сизиф... Только для того, чтобы получить
ушат дерьма, потому что перестали работать вебприложения у большой
массы пользователей, которые не успели поставить на холд старый питон,
а новый просто не тестировали из-за постоянного движняка в этом
таске... Если же все те же операции выполнить в публичном месте,
допускающем появления анметов и не проверяющих acl, то подготовка к
вбросу в Сизиф python2.6 займет неделю-две. Можно анонсировать его
появление и попросить заинтересованных протестировать его
функциональность. Для перемещения всего этого куска, останется только
запросить acl у мантейнеров соответствующих пакетов в Сизифе, или
получить nmu по нашему полиси. Для мантейнеров доступно будет ревью
как исходного кода в git, так и бинарного, пригодного к установке и
тестированию, в experimental.

Другой пример:
готовиться библиотека со сменой api/abi. Мантейнерам зависимых пакетов
нужно протестировать ФУНКЦИОНАЛЬНОСТЬ сборки с этой версией, прежде
чем забрасывать в unstable.

Если эти примеры на убеждают в необходимости experimental, то
аргументы у меня закончились, как и желание в дальнейшем обсуждать эту
тему.
-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] Бранчи и прочее

[Damir Shayhutdinov]

> таске... Если же все те же операции выполнить в публичном месте,
> допускающем появления анметов и не проверяющих acl, то подготовка к
> вбросу в Сизиф python2.6 займет неделю-две. Можно анонсировать его
> появление и попросить заинтересованных протестировать его
> функциональность.
Это практически дословное описание ftp:/people или любого внешнего ресурса.

> Для перемещения всего этого куска, останется только
> запросить acl у мантейнеров соответствующих пакетов в Сизифе, или
> получить nmu по нашему полиси.
То же самое в случае с people.

> Для мантейнеров доступно будет ревью как исходного кода в git, так и
> бинарного, пригодного к установке и тестированию, в experimental.
То же самое в people.

> Другой пример:
> готовиться библиотека со сменой api/abi. Мантейнерам зависимых пакетов
> нужно протестировать ФУНКЦИОНАЛЬНОСТЬ сборки с этой версией, прежде
> чем забрасывать в unstable.
Чем people не устраивает?

Re: [devel] Бранчи и прочее

[Eugene Ostapets]

2009/9/8 Damir Shayhutdinov <damir altlinux.org>:
> Чем people не устраивает?
Спасибо за внимание, больше не буду вас отвлекать своими идеями.

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] Бранчи и прочее

[Damir Shayhutdinov]

> 2009/9/8 Damir Shayhutdinov <damir altlinux.org>:
>> Чем people не устраивает?
> Спасибо за внимание, больше не буду вас отвлекать своими идеями.

Угу, но похоже и ftp: people пользоваться не будете. Был бы толк от
таких жестов....

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

Re: [devel] Бранчи и прочее

[Eugene Ostapets]

2009/9/8 Damir Shayhutdinov <damir altlinux.org>:
>> 2009/9/8 Damir Shayhutdinov <damir altlinux.org>:
>>> Чем people не устраивает?
>> Спасибо за внимание, больше не буду вас отвлекать своими идеями.
>
> Угу, но похоже и ftp: people пользоваться не будете. Был бы толк от
> таких жестов....
У меня уже есть собственный people с устраивающей меня инфраструктурой
сборки и пересборки, и еще один мне не нужен.
>
> А вопрос то интересный - что именно нужно сделать, чтобы улучшить тот
> уровень сервиса, который предоставляется сейчас через ftp? Пока судя
> по запросам - всего должно хватать. Или хочется сделать единый people,
> в котором одновременно будет несколько экспериментов проводиться?
Я вообще не знаю зачем нужен people на ftp. Я просто не вижу ни
единого применения для него, остальные, похоже, тоже не видят.


-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] Бранчи и прочее

[Dmitry V. Levin]

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

On Tue, Sep 08, 2009 at 10:03:32AM +0300, Eugene Ostapets wrote:
> 2009/9/8 Dmitry V. Levin <ldv altlinux.org>:
> > On Mon, Sep 07, 2009 at 07:55:25AM +0300, Eugene Ostapets wrote:
> >> Попытаюсь выразить свое более связно видение бранчей, близкое к
> >> теперешним техническим возможностям git.alt, при реализации которого,
> >> я безусловно буду заинтересован в работе над такими бранчами:
> >>
> >> 1. Карманы сложны для раелизации, но можно предоставить более-менее
> >> публичное место для технологических экспериментов, такой себе
> >> experimental (Daedalus из ныне живущих), со следующими свойствами:
> >> а) нет acl (вообще нет!!!)
> >> б) допускается публикация исключительно из git
> >> в) проверяется наследование истории по git
> >> г) публикация пакета другим мантейнером возможна только через какой-то
> >> промежуток времени (мне кажется 5 дней достаточно)
> >> д) анметы в данном репозитарии допускаются
> >
> > Похоже на описание разновидности кармана, с той существенной разницей, что
> > он единый и обязательный для всех.  Для полноты картины нужно описать
> > жизненный цикл одного пакета в этом кармане.
> Он обязательный по полиси, но не технологически.
> Рассмотрим пример python2.6:

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


-- 
ldv

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

Re: [devel] Бранчи и прочее

[Eugene Ostapets]

2009/9/8 Dmitry V. Levin <ldv altlinux.org>:
> Евгений, это ответ на другой воспрос.  Опишите мне жизненный цикл одного
> пакета в этом кармане, пожалуйста.  Иначе у меня нет никакой уверенности
> в том, что я хотя бы правильно понял то, что вы хотели сказать.
Хм... Кажется я туплю и не совсем понимаю какого описания от меня ждут :)

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

По умолчанию:
somepackage-X.Y.altZ+1.rpm является тривиальным исправлением и может
быть направлен сразу в unstable, откуда по итогам размышлений RM/QA
бранча может быть скопирован в p5/c5 (testing)
somepackage-X.Y+1.alt1.rpm является значимым изменением и его
желательно провести через experimental, для оценки функциональных
последствий обновления.
somepackage-X+1.0.alt1.rpm является критическим изменением и он обязан
пройти чистилище experimental перед публикацией в unstable.

somepackage-X.Y.altZ+1.rpm так же может содержать значимые или
критические изменения (вспоминая перепиливания структуры конфигов для
apache1/apache2) и по полиси должен пройти функциональное тестирование
в experimental.

Пакет из experimental не может быть скопирован в unstable, если
выявлены функциональные баги.
-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] Бранчи и прочее

[Michael Shigorin]

On Mon, Sep 07, 2009 at 02:35:57PM +0800, REAL wrote:
> >Нет, даже API/ABI менять нежелательно (в main нельзя?),
> >не говоря уже о смене тулчейна
> Пожалуй, соглашусь. Только тогда нужно изначально чётко
> очертить границы main с какими-то возможностями двигания этих
> границ (скажем, необходимо обновить что-то не общесистемное, но
> требующее по зависимостям обновления/пересборки ряда других
> пакетов).

Базовая сборочная плюс явно озвученное майнтейнерами.

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

[devel] backports (was: Бранчи и прочее)

[Michael Shigorin]

On Mon, Sep 07, 2009 at 10:23:53AM +0400, Aleksey Novodvorsky wrote:
> Я не понимаю, зачем нужен backports. Мне кажется, что судьба
> его будет печальна.

http://lists.altlinux.org/pipermail/devel/2008-August/158988.html
http://lists.altlinux.org/pipermail/devel/2008-May/154731.html

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

Re: [devel] Бранчи и прочее

[Michael Shigorin]

On Mon, Sep 07, 2009 at 09:32:58AM +0300, Eugene Ostapets wrote:
> Пока что у нас нет ни полиси на backports

Это не так.

> ни инфраструктуры для него...

А это так.

> Я верю, что он будет живым, потому что у меня перед глазами
> примеры Debian/Suse/Redhat, не понимаю, почему нам бэкпорты
> нужны меньше, чем им?

Дело в том, что я так и не наладил фидбэк хотя бы вроде того,
что был сделан для пакетов, прошедших в Daedalus.  Ну и вручную
разгребал с непредсказуемой периодичностью.

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

Re: [devel] Бранчи и прочее

[Eugene Ostapets]

2009/9/9 Michael Shigorin <mike osdn.org.ua>:
> On Mon, Sep 07, 2009 at 09:32:58AM +0300, Eugene Ostapets wrote:
>> Пока что у нас нет ни полиси на backports
>
> Это не так.
Миш, имеющееся полиси описывает только правила именования релизов :(
Не описаны ни правила учета зависимостей, ни правила урегулирования
конфликтов, которые однозначно будут возникать для долгоживущих
бранчей, если бэкпорты оживут. Нет требований по наследованию от
пакетов присутствующих в других репо и т.п. Вероятно это должен быть
комплект документов, но их содержание лучше формировать и обсуждать
людям, которые планируют активно наполнять этот оверлей, а не всем
скучающим прохожим...

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

[devel] experimental "vs" people (was: Бранчи и прочее)

[Michael Shigorin]

On Tue, Sep 08, 2009 at 12:30:34PM +0400, Damir Shayhutdinov wrote:
> > Другой пример: готовиться библиотека со сменой api/abi.
> > Мантейнерам зависимых пакетов нужно протестировать
> > ФУНКЦИОНАЛЬНОСТЬ сборки с этой версией, прежде чем
> > забрасывать в unstable.
> Чем people не устраивает?

Ну ты даёшь... people -- это файлопомойка, а не инфраструктура.

И единственный известный мне случай /people/gnome является особым
в т.ч. в части сетупа.  Сильно не уверен, что городить ситуативные
/people/python-2.6 не надоест быстро.

А возникают такие задачи пока не настолько часто,
чтоб пересечения над одним experimental решать
технологически, а не в договорном порядке.

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

Re: [devel] Бранчи и прочее

[REAL]

Michael Shigorin пишет:
>> Пожалуй, соглашусь. Только тогда нужно изначально чётко
>> очертить границы main с какими-то возможностями двигания этих
>> границ (скажем, необходимо обновить что-то не общесистемное, но
>> требующее по зависимостям обновления/пересборки ряда других
>> пакетов).
> Базовая сборочная плюс явно озвученное майнтейнерами.

Кстати, совсем забыл ещё один момент. Связанный с python 2.6.

Сейчас приходится выбрасывать файлы с питоновскими пакетами из сизифа 
на входе, а при обновлении пересобирать у себя. Боюсь, в нынешних 
обстоятельствах такая схема сохранится. Поэтому вопрос: когда именно 
будет новый (открытый) бранч создан? Может быть, дождаться всё же 
обновления питона, чтобы старый 2.5 опять не задержался в живых ещё на 
пару лет?

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] Бранчи и прочее (смысл названий)

[Michael Shigorin]

On Tue, Sep 08, 2009 at 12:10:07PM +0300, Eugene Ostapets wrote:
> Пакет из experimental не может быть скопирован в unstable,
> если выявлены функциональные баги.

Мне почему-то кажется, что ты подвинул на ступеньку вверх
ожидания качества/стабильности -- unstable может не работать,
а вот testing должен бы.  В experimental я бы предпочёл класть
именно эксперименты, а не все мажоры в обязательном порядке.

PS: может, попробуем на вики сформулировать -- кто в каком
качестве видит вообще разные репозитории и какое значение придаёт
словам?  Уж больно много копий сломано над разными определениями.

Мои старые попытки здесь (почему форкнулось -- не помню):
http://www.altlinux.org/Concepts/Context
http://www.altlinux.org/Concepts/Definitions

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

Re: [devel] Бранчи и прочее (backports)

[Michael Shigorin]

On Wed, Sep 09, 2009 at 11:51:17AM +0300, Eugene Ostapets wrote:
> >> Пока что у нас нет ни полиси на backports
> > Это не так.
> Миш, имеющееся полиси описывает только правила именования релизов :(

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

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

Давай для эксперимента прикрутим автопересобиралку к bp/4.0,
которые наиболее живые.  И оживим backports@.  И будем думать
над комплектом документов с этими самыми людьми.

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

Re: [devel] Бранчи и прочее (смысл названий)

[Eugene Ostapets]

2009/9/9 Michael Shigorin <mike osdn.org.ua>:
> On Tue, Sep 08, 2009 at 12:10:07PM +0300, Eugene Ostapets wrote:
>> Пакет из experimental не может быть скопирован в unstable,
>> если выявлены функциональные баги.
>
> Мне почему-то кажется, что ты подвинул на ступеньку вверх
> ожидания качества/стабильности -- unstable может не работать,
> а вот testing должен бы.  В experimental я бы предпочёл класть
> именно эксперименты, а не все мажоры в обязательном порядке.
Нет, unstable - это означает, что баги возможны, но не обязательны.
Если бага обнаружена на этапе experimental, такой пакет нельзя
переносить в unstable до исправления бага.
Пока у нас не будет достаточного количества мантейнеров, которые
повседневно используют ВСЕ свои пакеты, то мажоры должна проходить
через чистилище experimental... Особенно это касается пакетов
человека-робота lav@, которые пакетирует все, что запрашивают
пользователи, но сам не имеет ни времени, ни особого желания проверять
их на качество. :)


-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

[devel] *sigh*

[Michael Shigorin]

On Wed, Sep 09, 2009 at 12:05:35PM +0300, Eugene Ostapets wrote:
> Особенно это касается пакетов человека-робота lav@, которые
> пакетирует все, что запрашивают пользователи, но сам не имеет
> ни времени, ни особого желания проверять их на качество. :)

Ты с этим примером не более конструктивен, чем Дамир с /people.

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

Re: [devel] *sigh*

[Eugene Ostapets]

2009/9/9 Michael Shigorin <mike osdn.org.ua>:
> On Wed, Sep 09, 2009 at 12:05:35PM +0300, Eugene Ostapets wrote:
>> Особенно это касается пакетов человека-робота lav@, которые
>> пакетирует все, что запрашивают пользователи, но сам не имеет
>> ни времени, ни особого желания проверять их на качество. :)
>
> Ты с этим примером не более конструктивен, чем Дамир с /people.
Я даже смайл поставил. Или для тебя откровение, что у всех мантейнеров
с 50+ пакетов, вряд ли более половины проходят функциональное
тестирование? Какие-то пакеты собирались по просьбе пользователей,
что-то подхватывалось из-за сборочных зависимостей своих пакетов и
т.п. Далеко не все мантейнеры вообще понимают предметную область
такого пакета и способны протестировать что-то большее, чем
запускается-не запускается...


-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] *sigh*

[Eugene Ostapets]

2009/9/9 Victor Forsyuk <vvforce gmail.com>:
>
> 2009/9/9 Eugene Ostapets <eostapets gmail.com>
>>
>> 2009/9/9 Michael Shigorin <mike osdn.org.ua>:
>> > On Wed, Sep 09, 2009 at 12:05:35PM +0300, Eugene Ostapets wrote:
>> >> Особенно это касается пакетов человека-робота lav@, которые
>> >> пакетирует все, что запрашивают пользователи, но сам не имеет
>> >> ни времени, ни особого желания проверять их на качество. :)
>> >
>> > Ты с этим примером не более конструктивен, чем Дамир с /people.
>> Я даже смайл поставил. Или для тебя откровение, что у всех мантейнеров
>> с 50+ пакетов, вряд ли более половины проходят функциональное
>> тестирование?
>
> Не у всех.
Я рад, что есть и исключения, но они только подтверждают правило...


-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] *sigh*

[Eugene Ostapets]

2009/9/9 Victor Forsyuk <force altlinux.org>:
>
>
> 2009/9/9 Eugene Ostapets <eostapets gmail.com>
>> >> Я даже смайл поставил. Или для тебя откровение, что у всех мантейнеров
>> >> с 50+ пакетов, вряд ли более половины проходят функциональное
>> >> тестирование?
>> > Не у всех.
>> Я рад, что есть и исключения, но они только подтверждают правило...
> Можно узнать каким образом они подтверждают правило?
Для правила без исключений почти всегда можно подобрать более общее
правило с одним исключением :)


-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] *sigh*

[Dmitry V. Levin]

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

On Wed, Sep 09, 2009 at 12:14:01PM +0300, Eugene Ostapets wrote:
> 2009/9/9 Michael Shigorin <mike osdn.org.ua>:
> > On Wed, Sep 09, 2009 at 12:05:35PM +0300, Eugene Ostapets wrote:
> >> Особенно это касается пакетов человека-робота lav@, которые
> >> пакетирует все, что запрашивают пользователи, но сам не имеет
> >> ни времени, ни особого желания проверять их на качество. :)
> >
> > Ты с этим примером не более конструктивен, чем Дамир с /people.
> Я даже смайл поставил. Или для тебя откровение, что у всех мантейнеров
> с 50+ пакетов, вряд ли более половины проходят функциональное
> тестирование? Какие-то пакеты собирались по просьбе пользователей,
> что-то подхватывалось из-за сборочных зависимостей своих пакетов и
> т.п. Далеко не все мантейнеры вообще понимают предметную область
> такого пакета и способны протестировать что-то большее, чем
> запускается-не запускается...

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

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


-- 
ldv

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

Re: [devel] *sigh*

[Eugene Ostapets]

2009/9/9 Dmitry V. Levin <ldv altlinux.org>:
> - либо покидаете эту рассылку.
Да, я извиняюсь, что поднял эту тему, и вообще, что начал писать в эту рассылку.
>
> Вообще, человеку, за которым в Сизифе числится 0 поддерживаемых пакетов,
> следует быть более аккуратным при выборе формулировок.
У меня нет ни времени, ни желания устраивать разборки. Я останусь при
своем мнение, которое сформировалось на основе опыта работы с пакетами
АльтЛинукс, но хочу принести извинения тем мантейнерам, которые
действительно производят функциональное тестирование ВСЕХ собираемых
пакетов.

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] experimental "vs" people (was: Бранчи и прочее)

[Damir Shayhutdinov]

>> > Другой пример: готовиться библиотека со сменой api/abi.
>> > Мантейнерам зависимых пакетов нужно протестировать
>> > ФУНКЦИОНАЛЬНОСТЬ сборки с этой версией, прежде чем
>> > забрасывать в unstable.
>> Чем people не устраивает?
> Ну ты даёшь... people -- это файлопомойка, а не инфраструктура.

Имеется ввиду, что сделать rsync своего ~/hasher/repo на people можно
достаточно легко, а собирать из gear-репозитариев тех же в хешере так
же просто. Для того, чтобы эти две вещи объединить, нужно написать
простейший скрипт.
Или я что-то не понимаю?

Что мешает сделать некий сервис, который будет, используя тот же самый
гитальт, брать оттуда теги и собирать из них пакеты, устранять
дубликаты, индексировать и выкладывать в /people или в любое другое
доступное место? Обязательно хочется, чтобы этот софт разработали
программисты ООО?

> И единственный известный мне случай /people/gnome является особым
> в т.ч. в части сетупа.  Сильно не уверен, что городить ситуативные
> /people/python-2.6 не надоест быстро.
Миш, да так всегда. По своему опыту знаю, когда вместо решения
проблемы существующими способами (в соответствии с концепциями
unix-way) начинают выдумывать "лучшие способы" делания того же самого
- это называется "лень", и такое времяпрепровождение поощрять ни в
коем случае нельзя.

Нужен рабочий прототип карманов/experimental. От него требуется лишь
иллюстрация концепции, и практическое доказательство, что эта
концепция вообще жизнеспособна. В процессе написания такого прототипа
всплывет большинство проблем, о которых сейчас твердят at@ и ldv@, и
уже будет о чем предметно говорить.

Пока начальное мини-ТЗ для таких карманов полнее всего сформулировал
Женя. Но он все носится с идеей, что этим должно заниматься ООО, а
если оно не занимается - то Альт недостоин более читать письма Жени в
его рассылках. Дайте заняться этой задачей человеку, который надеется
только на свои силы - и он ее решит.

> А возникают такие задачи пока не настолько часто,
> чтоб пересечения над одним experimental решать
> технологически, а не в договорном порядке.
Мне не очень понятно, как "в договорном порядке" такое решать.
Питонщики должны договариваться с гномоводами, о том, когда именно они
будут "ломать" experimental?

По-моему мнению, способность решать что-то в договорном порядке
уменьшается экспоненциально при увеличении количества участников. Два
человека договорятся быстро, двадцать два человека не договорятся
никогда.

Re: [devel] experimental "vs" people (was: Бранчи и прочее)

[Alexey Rusakov]

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

В Срд, 09/09/2009 в 14:45 +0400, Damir Shayhutdinov пишет:
> >> > Другой пример: готовиться библиотека со сменой api/abi.
> >> > Мантейнерам зависимых пакетов нужно протестировать
> >> > ФУНКЦИОНАЛЬНОСТЬ сборки с этой версией, прежде чем
> >> > забрасывать в unstable.
> >> Чем people не устраивает?
> > Ну ты даёшь... people -- это файлопомойка, а не инфраструктура.
> 
> Имеется ввиду, что сделать rsync своего ~/hasher/repo на people можно
> достаточно легко, а собирать из gear-репозитариев тех же в хешере так
> же просто. Для того, чтобы эти две вещи объединить, нужно написать
> простейший скрипт.
> Или я что-то не понимаю?
Это уже обсуждали. /pub/people плох низкой discoverability и (даже не
знаю, причина это или следствие) indexability. Грубо говоря, ты не
можешь прикрутить /pub/people к sisyphus.ru, потому что непонятно, что и
где искать. Устраивать find по всему дереву - сам понимаешь, не годится.
Короче говоря, /pub/people - это не инфраструктура репозитория, это
файловая система. А нужна инфраструктура репозитория, попроще чем
нынешний Сизиф, но тем не менее.

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] experimental "vs" people (was: Бранчи и прочее)

[Eugene Ostapets]

2009/9/9 Damir Shayhutdinov <damir altlinux.org>:
> Что мешает сделать некий сервис, который будет, используя тот же самый
> гитальт, брать оттуда теги и собирать из них пакеты, устранять
> дубликаты, индексировать и выкладывать в /people или в любое другое
> доступное место? Обязательно хочется, чтобы этот софт разработали
> программисты ООО?
Есть софт, который разработали в etersoft, никто из имеющих право
смержить такое изменение публично не высказался ни по алгоритму
реализации, ни по качеству кода. Я вообще ни строчки кода не планирую
писать, пока идея не оформится и не получит поддержи - у меня есть чем
заняться в свободное от работы время.
>
>
> Но он все носится с идеей, что этим должно заниматься ООО, а
> если оно не занимается - то Альт недостоин более читать письма Жени в
> его рассылках. Дайте заняться этой задачей человеку, который надеется
> только на свои силы - и он ее решит.
Покажите мне мое письмо, где я говорил, что реализовать код обязан
ООО? Я хочу получить согласие владельцев инфраструктуры на расширение
в соответствии с обговоренным функционалом, но слышу лишь "напиши и
покажи код" или "это никому не нужно и не будет работать".

Если не устраивает работающий код etersoft, давайте обговорим его или
просто выработаем требования к коду, исходя из простой предпосылки,
когда знаешь что и как нужно написать, то написать приемлимый код с
первой попытки намного проще, чем положить в основу алгоритма
предположения, которые будут опровергнуты на этапе security review и
весь код придется переписать с нуля.

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] experimental "vs" people (was: Бранчи и прочее)

[Damir Shayhutdinov]

> Это уже обсуждали. /pub/people плох низкой discoverability и (даже не
> знаю, причина это или следствие) indexability. Грубо говоря, ты не
> можешь прикрутить /pub/people к sisyphus.ru, потому что непонятно, что и
> где искать. Устраивать find по всему дереву - сам понимаешь, не годится.
Низкая способность к интеграции с существующими сервисами все же
лучше, чем вообще отсутствие интеграции. Ждать, пока появится сервис с
высокой способностью к интеграции можно очень долго.

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

[sisyphus-cybertalk] Состояние gnome-кармана: обновлено еще 10
пакетов, осталось 35.

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

> Короче говоря, /pub/people - это не инфраструктура репозитория, это
> файловая система. А нужна инфраструктура репозитория, попроще чем
> нынешний Сизиф, но тем не менее.
Я понимаю, что хочется все и сразу. Но если не получается все и сразу,
почему не попробовать частями и потихоньку? Или это синдром Остапа
Бендера? "Я бы взял частями, но мне нужно сразу".

Re: [devel] experimental "vs" people (was: Бранчи и прочее)

[Damir Shayhutdinov]

> Есть софт, который разработали в etersoft, никто из имеющих право
> смержить такое изменение публично не высказался ни по алгоритму
> реализации, ни по качеству кода. Я вообще ни строчки кода не планирую
> писать, пока идея не оформится и не получит поддержи - у меня есть чем
> заняться в свободное от работы время.
Это называется "deadlock" - когда обе стороны хотят выполнения
каких-то условий, прежде чем
приступить к работе. Утром деньги - вечером стулья. А deadlock - это
типичная задачка для программиста.
Как ее решают обычно - ты, конечно, знаешь.

Идея гораздо быстрее оформится, если у нее будет рабочий прототип.
Хотя конечно, ты можешь мне не верить, но магия "show me the code"
таки работает.

> Покажите мне мое письмо, где я говорил, что реализовать код обязан
> ООО? Я хочу получить согласие владельцев инфраструктуры на расширение
> в соответствии с обговоренным функционалом, но слышу лишь "напиши и
> покажи код" или "это никому не нужно и не будет работать".

Зачем тебе нужно согласие владельцев инфраструктуры? Инфраструктура,
насколько мне известно, является открытой, и ООО не держит каких-то
секретных ключей от нее. Или нужна именно подпись Альта на всех
пакетах? Я просто никак не могу понять, в какой мере согласие или
несогласие владельцев инфраструктуры влияет на идею пакетов,
experimental и проч.

> Если не устраивает работающий код etersoft, давайте обговорим его или
> просто выработаем требования к коду, исходя из простой предпосылки,
> когда знаешь что и как нужно написать, то написать приемлимый код с
> первой попытки намного проще, чем положить в основу алгоритма
> предположения, которые будут опровергнуты на этапе security review и
> весь код придется переписать с нуля.

Лучше уж переписать, чем вообще ничего не писать из опасения, что
придется переписывать.

Re: [devel] experimental "vs" people (was: Бранчи и прочее)

[Eugene Ostapets]

2009/9/9 Damir Shayhutdinov <damir@altlinux.org>:
>> Есть софт, который разработали в etersoft, никто из имеющих право
>> смержить такое изменение публично не высказался ни по алгоритму
>> реализации, ни по качеству кода. Я вообще ни строчки кода не планирую
>> писать, пока идея не оформится и не получит поддержи - у меня есть чем
>> заняться в свободное от работы время.
> Это называется "deadlock" - когда обе стороны хотят выполнения
> каких-то условий, прежде чем
> приступить к работе. Утром деньги - вечером стулья. А deadlock - это
> типичная задачка для программиста.
> Как ее решают обычно - ты, конечно, знаешь.
Повторяю для тех, кто читает не то, что написано - ЕСТЬ КОД ОТ
ETERSOFT, реализующий идею карманов. Какие к нему претензии? Что
переделать? Что доделать?
>
> Идея гораздо быстрее оформится, если у нее будет рабочий прототип.
> Хотя конечно, ты можешь мне не верить, но магия "show me the code"
> таки работает.
Перечитайте еще раз письмо, которое цитируете - НЕ РАБОТАЕТ.
>
>> Покажите мне мое письмо, где я говорил, что реализовать код обязан
>> ООО? Я хочу получить согласие владельцев инфраструктуры на расширение
>> в соответствии с обговоренным функционалом, но слышу лишь "напиши и
>> покажи код" или "это никому не нужно и не будет работать".
>
> Зачем тебе нужно согласие владельцев инфраструктуры? Инфраструктура,
> насколько мне известно, является открытой, и ООО не держит каких-то
> секретных ключей от нее. Или нужна именно подпись Альта на всех
> пакетах? Я просто никак не могу понять, в какой мере согласие или
> несогласие владельцев инфраструктуры влияет на идею пакетов,
> experimental и проч.
Мы здесь обсуждаем частные инициативы? У меня есть бранч,
инфраструктура и все, что мне требуется. Если мы обсуждаем развитие
инфраструктуры для тим - то естественно я ожидаю итогового одобрения
держателей этой инфраструктуры.
>
>> Если не устраивает работающий код etersoft, давайте обговорим его или
>> просто выработаем требования к коду, исходя из простой предпосылки,
>> когда знаешь что и как нужно написать, то написать приемлимый код с
>> первой попытки намного проще, чем положить в основу алгоритма
>> предположения, которые будут опровергнуты на этапе security review и
>> весь код придется переписать с нуля.
>
> Лучше уж переписать, чем вообще ничего не писать из опасения, что
> придется переписывать.
Попробуйте читать не только концовки предложений, может тогда я смогу
понять смысл ваших комментариев.

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] experimental "vs" people (was: Бранчи и прочее)

[Damir Shayhutdinov]

> Повторяю для тех, кто читает не то, что написано - ЕСТЬ КОД ОТ
> ETERSOFT, реализующий идею карманов. Какие к нему претензии? Что
> переделать? Что доделать?
Надо сделать так, чтобы он работал, всего лишь. Сделай так, чтобы он работал.
Сделай хоть одну из запланированных тобой к решению с помощью этого
инструмента задач.
В качестве примера предлагаю Питон 2.6.

>> Идея гораздо быстрее оформится, если у нее будет рабочий прототип.
>> Хотя конечно, ты можешь мне не верить, но магия "show me the code"
>> таки работает.
> Перечитайте еще раз письмо, которое цитируете - НЕ РАБОТАЕТ.
Ты упустил важную деталь. _рабочий прототип_.

> Мы здесь обсуждаем частные инициативы? У меня есть бранч,
> инфраструктура и все, что мне требуется. Если мы обсуждаем развитие
> инфраструктуры для тим - то естественно я ожидаю итогового одобрения
> держателей этой инфраструктуры.

ALT Linux - это не только ООО, но и community. А "частная инициатива"
- суть этого самого community.
Что в КОДЕ ОТ ЭТЕРСОФТ _требует_ итогового одобрения держателей этой
инфраструктуры?

Это мне напоминает Доббса из Уловки-22:

{цитата}
Йоссариан мысленно проследил ход предстоящей операции.
    -- Ну, а в каком месте вхожу в игру я? -- спросил он, недоумевая.
    --  Без тебя я не возьмусь, -- объяснил Доббс. -- Мне нужно, чтобы ты
сказал: "Давай, Доббс, действуй!" Йоссариан не верил своим ушам.
    -- Это все, что тебе от меня нужно? Только сказать:
   - "Давай, Доббс, действуй"?
    -- Это все, что мне от тебя нужно, -- подтвердил Доббс. -- Скажи мне:
"Давай, действуй!" и послезавтра я вышибу ему мозги
{/цитата}

> Попробуйте читать не только концовки предложений, может тогда я смогу
> понять смысл ваших комментариев.
Не смею даже на это надеяться.

Re: [devel] experimental "vs" people (was: Бранчи и прочее)

[Michael Shigorin]

On Wed, Sep 09, 2009 at 02:45:07PM +0400, Damir Shayhutdinov wrote:
> Имеется ввиду, что сделать rsync своего ~/hasher/repo на people
> можно достаточно легко, а собирать из gear-репозитариев тех же
> в хешере так же просто. Для того, чтобы эти две вещи
> объединить, нужно написать простейший скрипт.
> Или я что-то не понимаю?

Групповые права, когда требуется участие нескольких человек.
Пример уже привели -- тот же python-2.6.

> Что мешает сделать некий сервис, который будет, используя тот
> же самый гитальт, брать оттуда теги и собирать из них пакеты,
> устранять дубликаты, индексировать и выкладывать в /people или
> в любое другое доступное место? Обязательно хочется, чтобы этот
> софт разработали программисты ООО?

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

Есть и ещё один момент: мы с Женей твердим о проблемах ИС,
которые критичны для увеличения масштабируемости команды.
Нас сюда позвали, мы откликнулись, в процессе сотрудничества
заметили проблемы в организации и потратив некислое количество
времени на их осмысление, а тут -- "шлите патчи".  Если бы
багрепорты без патчей не принимались, не знаю, что за фрисофт
был бы и где.  Потому необязательно, но зовя, стоит думать,
а дальше-то что.

> > А возникают такие задачи пока не настолько часто,
> > чтоб пересечения над одним experimental решать
> > технологически, а не в договорном порядке.
> Мне не очень понятно, как "в договорном порядке" такое решать.
> Питонщики должны договариваться с гномоводами, о том, когда
> именно они будут "ломать" experimental?

Да, пока это не получится сделать более fine grained.

> По-моему мнению, способность решать что-то в договорном порядке
> уменьшается экспоненциально при увеличении количества
> участников. Два человека договорятся быстро, двадцать два
> человека не договорятся никогда.

Конечно.  Но сейчас у нас нет и такого тыла, кроме примера
/people/gnome + gnome@.

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

Re: [devel] experimental "vs" people (was: Бранчи и прочее)

[Eugene Ostapets]

2009/9/9 Damir Shayhutdinov <damir altlinux.org>:
>> Повторяю для тех, кто читает не то, что написано - ЕСТЬ КОД ОТ
>> ETERSOFT, реализующий идею карманов. Какие к нему претензии? Что
>> переделать? Что доделать?
> Надо сделать так, чтобы он работал, всего лишь. Сделай так, чтобы он работал.
> Сделай хоть одну из запланированных тобой к решению с помощью этого
> инструмента задач.
> В качестве примера предлагаю Питон 2.6.
Т.е. я должен обратиться в etersoft с просьбой предоставить доступ к
их инфраструктуре всем желающим поучаствовать в работе над python2.6?
Спасибо, посмеялся, пишите еще!

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] experimental "vs" people (was: Бранчи и прочее)

[Damir Shayhutdinov]

>> в хешере так же просто. Для того, чтобы эти две вещи
>> объединить, нужно написать простейший скрипт.
>> Или я что-то не понимаю?
>
> Групповые права, когда требуется участие нескольких человек.
> Пример уже привели -- тот же python-2.6.
А как вообще права применимы к тому же people? Я на своей машине волен
собирать все, что захочу.

Или имеется ввиду момент, когда "карман" мержится в Сизиф, т.е.
автоматизация создания shared task - получения NMU, взаимодействие с
мантейнерами чтобы они добавляли свои git-ы или .src.rpm к shared
task?

> Нет, необязательно.  Просто это приличный (для меня) кусок
> работы, который после реализации обязательно встанет перед
> выбором -- так и жить в сторонке или интегрироваться с ИС.
Возможно. я так до сих пор и не понимаю, но по-моему, уже работающему сервису
интегрироваться с ИС гораздо легче. Код написан, отлажен, если
требуются какие-то
доводки для интеграции - они делаются. В качестве примера можно
привести repocop.

> Есть и ещё один момент: мы с Женей твердим о проблемах ИС,
> которые критичны для увеличения масштабируемости команды.
> Нас сюда позвали, мы откликнулись, в процессе сотрудничества
> заметили проблемы в организации и потратив некислое количество
> времени на их осмысление, а тут -- "шлите патчи".  Если бы
> багрепорты без патчей не принимались, не знаю, что за фрисофт
> был бы и где.  Потому необязательно, но зовя, стоит думать,
> а дальше-то что.
Миш, вы опасаетесь, что работа будет выполнена впустую? Что вы
сделаете решение,
которое будет неинтегрируемым? Или невостребованным? Вы хотите
каких-то гарантий
со стороны ООО, что решение будет внедрено в любом случае, даже если оно
невостребованное и/или неинтегрируемое? Или хотите чтобы ООО тоже
участвовало в решении,
потому что вам не хватает сил? Насколько я понял, ни ldv@, ни at@ не
понимают, чего от них хотят.

>> > А возникают такие задачи пока не настолько часто,
>> > чтоб пересечения над одним experimental решать
>> > технологически, а не в договорном порядке.
>> Мне не очень понятно, как "в договорном порядке" такое решать.
>> Питонщики должны договариваться с гномоводами, о том, когда
>> именно они будут "ломать" experimental?
> Да, пока это не получится сделать более fine grained.
Как единый experimental в этом поможет? Как можно тестировать Питон,
если разломан Гном?
Ставить на время тестирования какой-то другой DE? Или устанавливать
выборочно - либо новый Питон, либо новый Гном, чтобы в любой момент
было сломано максимум что-то одно? Это автоматически уводит от идеи
dist-upgrade к идее выборочного install, а для таких задач у нас
Daedalus вроде как есть. Или к раздельным карманам, которые можно
подключать независимо (тут вопрос - а такое вообще возможно без риска
разлома системы?)

> Конечно.  Но сейчас у нас нет и такого тыла, кроме примера
> /people/gnome + gnome@.
Угу, и вам очень хочется наладить взаимодействие многих мантейнеров
техническими средствами, уйдя от премодерации к постмодерации.

Re: [devel] experimental "vs" people (was: Бранчи и прочее)

[Damir Shayhutdinov]

>> Надо сделать так, чтобы он работал, всего лишь. Сделай так, чтобы он работал.
>> Сделай хоть одну из запланированных тобой к решению с помощью этого
>> инструмента задач.
>> В качестве примера предлагаю Питон 2.6.
> Т.е. я должен обратиться в etersoft с просьбой предоставить доступ к
> их инфраструктуре всем желающим поучаствовать в работе над python2.6?
> Спасибо, посмеялся, пишите еще!

Инфраструктура etersoft закрыта, и ее воспроизвести на собственных
мощностях не получается? Тогда да, придется просить. И мне было бы
интересно узнать, откажут они или нет. То есть заинтересованы они в
python2.6, и в ускорении групповой работы вокруг Сизифа, или нет.

Re: [devel] experimental "vs" people (was: Бранчи и прочее)

[Eugene Ostapets]

2009/9/9 Damir Shayhutdinov <damir altlinux.org>:
>>> Надо сделать так, чтобы он работал, всего лишь. Сделай так, чтобы он работал.
>>> Сделай хоть одну из запланированных тобой к решению с помощью этого
>>> инструмента задач.
>>> В качестве примера предлагаю Питон 2.6.
>> Т.е. я должен обратиться в etersoft с просьбой предоставить доступ к
>> их инфраструктуре всем желающим поучаствовать в работе над python2.6?
>> Спасибо, посмеялся, пишите еще!
>
> Инфраструктура etersoft закрыта, и ее воспроизвести на собственных
> мощностях не получается?
Зачем мне их инфраструктура на моих мощностях? Меня в устраивает моя
инфраструктура, но она не ставила себе целью групповую разработку и не
пригодна для решения этой задачи.

> Тогда да, придется просить.
Т.е. Вы от лица всего тим уполномочиваете меня обратиться к
коммерческой компании за ее ресурсами? А не много Вы на себя берете?

> И мне было бы
> интересно узнать, откажут они или нет. То есть заинтересованы они в
> python2.6, и в ускорении групповой работы вокруг Сизифа, или нет.
Спросите у них сами, потом расскажете их ответ, если будет разрешение
на оглашение хода переговоров.

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] experimental "vs" people (was: Бранчи и прочее)

[Mykola S. Grechukh]

9 сентября 2009 г. 15:40 пользователь Eugene Ostapets () написал:
> 2009/9/9 Damir Shayhutdinov <damir altlinux.org>:
>>>> Надо сделать так, чтобы он работал, всего лишь. Сделай так, чтобы он работал.
>>>> Сделай хоть одну из запланированных тобой к решению с помощью этого
>>>> инструмента задач.
>>>> В качестве примера предлагаю Питон 2.6.
>>> Т.е. я должен обратиться в etersoft с просьбой предоставить доступ к
>>> их инфраструктуре всем желающим поучаствовать в работе над python2.6?
>>> Спасибо, посмеялся, пишите еще!
>>
>> Инфраструктура etersoft закрыта, и ее воспроизвести на собственных
>> мощностях не получается?
> Зачем мне их инфраструктура на моих мощностях?

Гм, в качестве proof of concept?

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

таки действительно, в чём идея ? Ответственные за текущую
инфраструктуру git.alt должны немедленно побежать прикручивать
разработки Etersoft к git.alt "на посмотреть" ?

Re: [devel] experimental "vs" people (was: Бранчи и прочее)

[Damir Shayhutdinov]

>> Инфраструктура etersoft закрыта, и ее воспроизвести на собственных
>> мощностях не получается?
> Зачем мне их инфраструктура на моих мощностях? Меня в устраивает моя
> инфраструктура, но она не ставила себе целью групповую разработку и не
> пригодна для решения этой задачи.

Тогда я не понимаю, что вы хотите. Вам по какой-то причине не нужна
инфраструктура Этерсофт на ваших мощностях, но вы хотите внедрить ее
на мощностях ООО. Одному мне это кажется странным?

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

> Спросите у них сами, потом расскажете их ответ, если будет разрешение
> на оглашение хода переговоров.
То есть вы просите меня, попросить Etersoft, разрешить вам
использовать инфраструктуру Etersoft, для того, чтобы произвести
эксперимент по внедрению копии этой структуры в OOO "Alt Linux"?

А сами вы провести такой эксперимент отказываетесь, потому что "Меня
устраивает моя инфраструктура, но она под это не заточена"?

Ну и ЧЕМ конкретно вы лучше ООО в данном случае? У них абсолютно такая
же аргументация. Стоило тратить столько времени, чтобы выяснить это?

Я то думал, что из этого обсуждения выльется что-то полезное для
сообщества ALT Linux Team. Пока же видны только обиды "хозяйствующих
субьектов", каждая из которых не хочет держать что-то подобное на
своих мощностях. Это очень грустно.

Re: [devel] experimental "vs" people (was: Бранчи и прочее)

[Eugene Ostapets]

2009/9/9 Mykola S. Grechukh <nick.grechukh gmail.com>:
> 9 сентября 2009 г. 15:40 пользователь Eugene Ostapets () написал:
>>> Инфраструктура etersoft закрыта, и ее воспроизвести на собственных
>>> мощностях не получается?
>> Зачем мне их инфраструктура на моих мощностях?
> Гм, в качестве proof of concept?
Разве что... Но это к mike@, он когда вернется, сделает контейнер,
разберется с запуском и т.п. Мне для бизнеса такая инфраструктура не
нужна на текущий момент.
>
>> Меня в устраивает моя
>> инфраструктура, но она не ставила себе целью групповую разработку и не
>> пригодна для решения этой задачи.
>
> таки действительно, в чём идея ? Ответственные за текущую
> инфраструктуру git.alt должны немедленно побежать прикручивать
> разработки Etersoft к git.alt "на посмотреть" ?
Они так много кричали "покажи код"... Я ожидаю, что они посмотрят
предложенный код и хотя в общих словах обоснуют, почему этот код
нельзя использовать на git.alt. Или честно скажут, что никакие карманы
никогда и ни в каком случае не будут доступны на git.alt, а значит тим
должен сам озадачиться аппаратными ресурсами для организации
инфраструктуры. Это тоже вполне допустимый вариант. Просто хочется
понять, возможно ли взаимодействие между командой и ООО по поводу
инфраструктуры, или нет.

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] experimental "vs" people (was: Бранчи и прочее)

[Damir Shayhutdinov]

>> таки действительно, в чём идея ? Ответственные за текущую
>> инфраструктуру git.alt должны немедленно побежать прикручивать
>> разработки Etersoft к git.alt "на посмотреть" ?
> Они так много кричали "покажи код"... Я ожидаю, что они посмотрят
> предложенный код и хотя в общих словах обоснуют, почему этот код
> нельзя использовать на git.alt.

Насколько я понял, интересен не сам код, а результат его запуска. И
когда просят "show me the code" - требуют чтобы он хотя бы работал, и
можно было видеть результат, а уж потом - каким способом он был
достигнут.

Re: [devel] experimental "vs" people (was: Бранчи и прочее)

[Eugene Ostapets]

2009/9/9 Damir Shayhutdinov <damir altlinux.org>:
>>> таки действительно, в чём идея ? Ответственные за текущую
>>> инфраструктуру git.alt должны немедленно побежать прикручивать
>>> разработки Etersoft к git.alt "на посмотреть" ?
>> Они так много кричали "покажи код"... Я ожидаю, что они посмотрят
>> предложенный код и хотя в общих словах обоснуют, почему этот код
>> нельзя использовать на git.alt.
>
> Насколько я понял, интересен не сам код, а результат его запуска. И
> когда просят "show me the code" - требуют чтобы он хотя бы работал, и
> можно было видеть результат, а уж потом - каким способом он был
> достигнут.
Он работает. Вопрос в том, насколько он заточен под нужды его
разработчиков? Я думаю очень сильно. Насколько он совместим с кодом
git.alt? Быстрый и качественный ответ могут дать только разработчики
того и другого, после личного общения. Насколько он нужен ALTLinux
Team? Вот на это вопрос и мы сейчас и хотим ответить... А последний
вопрос - имеет ли этот код перспективу интеграции в git.alt, самый
сложный и я склоняюсь к мысли, что ответ отрицательный... Идея
поставить experimental перед unstable для критических изменений в
пакетах возникла именно исходя из предположения об отрицательно ответе
на идею карманов. Переписывание кода git.alt для этого будет
минимальным и не затрагивающим базовые алгоритмы, почти все выносится
за пределы технической реализации - в полиси. Но и эта идея вызывает,
пока что, только неконструктивную критику.


-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] experimental "vs" people (was: Бранчи и прочее)

[Eugene Ostapets]

2009/9/9 Damir Shayhutdinov <damir altlinux.org>:
>> Спросите у них сами, потом расскажете их ответ, если будет разрешение
>> на оглашение хода переговоров.
> То есть вы просите меня, попросить Etersoft, разрешить вам
> использовать инфраструктуру Etersoft, для того, чтобы произвести
> эксперимент по внедрению копии этой структуры в OOO "Alt Linux"?
Вы не запутались кто и что вам должен?
>
> А сами вы провести такой эксперимент отказываетесь, потому что "Меня
> устраивает моя инфраструктура, но она под это не заточена"?
>
> Ну и ЧЕМ конкретно вы лучше ООО в данном случае? У них абсолютно такая
> же аргументация. Стоило тратить столько времени, чтобы выяснить это?
>
> Я то думал, что из этого обсуждения выльется что-то полезное для
> сообщества ALT Linux Team. Пока же видны только обиды "хозяйствующих
> субьектов", каждая из которых не хочет держать что-то подобное на
> своих мощностях. Это очень грустно.
Меня уже утомили эти претензии... Сначала было "Покажи код", теперь
"Докажи, что он подходит для решения задач", потом я так понимаю
потребуется математическое доказательство, что несколько сот пакетов,
собранных в таком кармане, могут быть отправлены в Сизиф? А потом?
Может сразу огласите весь список претензий, чтобы можно было
распланировать свое свободное время на 5 лет вперед?


-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] experimental "vs" people (was: Бранчи и прочее)

[Damir Shayhutdinov]

>> То есть вы просите меня, попросить Etersoft, разрешить вам
>> использовать инфраструктуру Etersoft, для того, чтобы произвести
>> эксперимент по внедрению копии этой структуры в OOO "Alt Linux"?
> Вы не запутались кто и что вам должен?
Нет.

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

>> Я то думал, что из этого обсуждения выльется что-то полезное для
>> сообщества ALT Linux Team. Пока же видны только обиды "хозяйствующих
>> субьектов", каждая из которых не хочет держать что-то подобное на
>> своих мощностях. Это очень грустно.
> Меня уже утомили эти претензии... Сначала было "Покажи код", теперь
> "Докажи, что он подходит для решения задач", потом я так понимаю
> потребуется математическое доказательство, что несколько сот пакетов,
> собранных в таком кармане, могут быть отправлены в Сизиф?

Собери питон2.6 в Сизиф таким образом. Мне бы этого хватило. Но я не
ООО, так что мои "претензии", как ты их называешь, можно и не
принимать во внимание. Принимай во внимание претензии ldv@ и at@ :P

Re: [devel] experimental "vs" people (was: Бранчи и прочее)

[Mykola S. Grechukh]

9 сентября 2009 г. 16:16 пользователь Eugene Ostapets () написал:
> Меня уже утомили эти претензии... Сначала было "Покажи код", теперь
> "Докажи, что он подходит для решения задач", потом я так понимаю
> потребуется математическое доказательство, что несколько сот пакетов,
> собранных в таком кармане, могут быть отправлены в Сизиф? А потом?

мне всегда казалось, что Show me [your] code в контексте улучшения
инфраструктуры подразумевает предъявление НЕ десяти килобайт "чего-то"
делающего "что-то", а рабочей инсталляции и хоть какой-то
документации.

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

-- 
Mykola Grechukh
RISC Group IT Solutions

Re: [devel] experimental "vs" people (was: Бранчи и прочее)

[Eugene Ostapets]

2009/9/9 Damir Shayhutdinov <damir altlinux.org>:
>>> То есть вы просите меня, попросить Etersoft, разрешить вам
>>> использовать инфраструктуру Etersoft, для того, чтобы произвести
>>> эксперимент по внедрению копии этой структуры в OOO "Alt Linux"?
>> Вы не запутались кто и что вам должен?
> Нет.
>
> Я просил показать, что код работает, на примере питон2.6
Ок, в соседнем треде etersoft согласился сам произвести эксперимент со
сборкой питона... Вывод можно сделать один - нужно сменить название с
ALTLinux Team на Etersoft Team и перебираться со всеми работами туда.
Все готовы?

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] experimental "vs" people (was: Бранчи и прочее)

[Dmitry V. Levin]

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

On Wed, Sep 09, 2009 at 04:48:52PM +0300, Eugene Ostapets wrote:
> 2009/9/9 Damir Shayhutdinov <damir altlinux.org>:
> >>> То есть вы просите меня, попросить Etersoft, разрешить вам
> >>> использовать инфраструктуру Etersoft, для того, чтобы произвести
> >>> эксперимент по внедрению копии этой структуры в OOO "Alt Linux"?
> >> Вы не запутались кто и что вам должен?
> > Нет.
> >
> > Я просил показать, что код работает, на примере питон2.6
> Ок, в соседнем треде etersoft согласился сам произвести эксперимент со
> сборкой питона... Вывод можно сделать один - нужно сменить название с
> ALTLinux Team на Etersoft Team и перебираться со всеми работами туда.
> Все готовы?

Евгений, покажите нам пример, пожалуйста.  Очень буду вам признателен.


-- 
ldv

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

Re: [devel] experimental "vs" people (was: Бранчи и прочее)

[Damir Shayhutdinov]

> Ок, в соседнем треде etersoft согласился сам произвести эксперимент со
> сборкой питона... Вывод можно сделать один - нужно сменить название с
> ALTLinux Team на Etersoft Team и перебираться со всеми работами туда.
> Все готовы?
А я думал, нас там не ждут, и нам туда проситься надо... А оказывается
вот оно как...

Re: [devel] experimental "vs" people (was: Бранчи и прочее)

[Денис Смирнов]

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

On Wed, Sep 09, 2009 at 02:45:07PM +0400, Damir Shayhutdinov wrote:

DS> Нужен рабочий прототип карманов/experimental. От него требуется лишь
DS> иллюстрация концепции, и практическое доказательство, что эта
DS> концепция вообще жизнеспособна. В процессе написания такого прототипа
DS> всплывет большинство проблем, о которых сейчас твердят at@ и ldv@, и
DS> уже будет о чем предметно говорить.

Я неправильно понял письма коллег, или такой прототип уже успешно работает
в Etersoft?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] experimental "vs" people (was: Бранчи и прочее)

[Денис Смирнов]

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

On Wed, Sep 09, 2009 at 04:32:25PM +0400, Damir Shayhutdinov wrote:

DS> Ставить на время тестирования какой-то другой DE? Или устанавливать
DS> выборочно - либо новый Питон, либо новый Гном, чтобы в любой момент
DS> было сломано максимум что-то одно? Это автоматически уводит от идеи
DS> dist-upgrade к идее выборочного install, а для таких задач у нас
DS> Daedalus вроде как есть. Или к раздельным карманам, которые можно
DS> подключать независимо (тут вопрос - а такое вообще возможно без риска
DS> разлома системы?)

Под единым expiremental и поздраумевается как раз доведенный до ума
Daedalus.

У меня есть предложение -- прежде чем изобретать всякие хитрости с
experimental, сделать следующее:

- добавить в git.alt поддержку Daedalus
- при сборке в Daedalus проверки на unmet'ы и на устанавливаемость
  проводить, но их неудача не должна приводить к блокированию пакета
- при сборке в Daedalus игнорировать acl

После этого может быть дальнейший предметный разговор об experimental.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] experimental "vs" people (was: Бранчи и прочее)

[Денис Смирнов]

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

On Wed, Sep 09, 2009 at 04:48:52PM +0300, Eugene Ostapets wrote:

EO> Ок, в соседнем треде etersoft согласился сам произвести эксперимент со
EO> сборкой питона... Вывод можно сделать один - нужно сменить название с
EO> ALTLinux Team на Etersoft Team и перебираться со всеми работами туда.
EO> Все готовы?

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

ALT, это:
- отлаженная, работающая инфраструктура, да еще и с открытыми кодами (на
  базе которых, как я понимаю, сделана инфраструктура git.eter)
- alterator
- инсталлятор
- инфраструктура для удобного выпекания своих дистрибутивов (и, как я
  понимаю, аналогичных решений такого же уровня удобства и функционала
  нет)

и многое другое.

А еще сотрудники ALT не всегда согласны с мнением каждого из участников
team, и это не всем нравится :)

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

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] Бранчи и прочее (смысл названий)

[Денис Смирнов]

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

On Wed, Sep 09, 2009 at 11:59:23AM +0300, Michael Shigorin wrote:
>> Пакет из experimental не может быть скопирован в unstable,
>> если выявлены функциональные баги.
MS> Мне почему-то кажется, что ты подвинул на ступеньку вверх
MS> ожидания качества/стабильности -- unstable может не работать,
MS> а вот testing должен бы.  В experimental я бы предпочёл класть
MS> именно эксперименты, а не все мажоры в обязательном порядке.

Если будет разделение main/contrib, то это требование будет разумным для
пакетов, входящих в main.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] experimental "vs" people (was: Бранчи и прочее)

[Michael Shigorin]

On Wed, Sep 09, 2009 at 03:58:45PM +0300, Eugene Ostapets wrote:
> >>> Инфраструктура etersoft закрыта, и ее воспроизвести на
> >>> собственных мощностях не получается?
> >> Зачем мне их инфраструктура на моих мощностях?
> > Гм, в качестве proof of concept?
> Разве что... Но это к mike@, он когда вернется, сделает
> контейнер, разберется с запуском и т.п. Мне для бизнеса такая
> инфраструктура не нужна на текущий момент.

Да я и отсюда могу на свободной машинке.  Ты скажи, что куда,
а дальше как обычно :-)

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

Re: [devel] experimental "vs" people (was: Бранчи и прочее)

[Michael Shigorin]

On Wed, Sep 09, 2009 at 04:32:25PM +0400, Damir Shayhutdinov wrote:
> >> Или я что-то не понимаю?
> > Групповые права, когда требуется участие нескольких человек.
> А как вообще права применимы к тому же people?
> Я на своей машине волен собирать все, что захочу.

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

> Или имеется ввиду момент, когда "карман" мержится в Сизиф, т.е.
> автоматизация создания shared task - получения NMU,
> взаимодействие с мантейнерами чтобы они добавляли свои git-ы
> или .src.rpm к shared task?

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

> Возможно. я так до сих пор и не понимаю, но по-моему, уже
> работающему сервису интегрироваться с ИС гораздо легче.
> Код написан, отлажен, если требуются какие-то доводки для
> интеграции - они делаются. В качестве примера можно привести
> repocop.

Понимаешь, сейчас вот icesik@ затеял переделывать prometeus.
Общего у них как минимум потрошилка пакетов.  Если заранее
придумать какой-то API ("хотя бы просигналить, где лежит
разобранный пакет"), можно сэкономить что-то минут 5--15
процессорного времени (не помню) и заметное количество i/o.

> Миш, вы опасаетесь, [...]

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

> Насколько я понял, ни ldv@, ни at@ не понимают, чего от них
> хотят.

Мне кажется, что Дима понимает, но до всего руки заведомо не
дойдут, а Лёша чрезмерно увлёкся математикой и порой ставит
красоту абстракции выше людей.  Пример с теми же версиями в
бранчах -- хорошо, что в #21264 нашёлся разумный компромисс.

Ещё мне кажется, что Дима не будет что-либо делать потому,
что об этом много кричат.

> >> > А возникают такие задачи пока не настолько часто,
> >> > чтоб пересечения над одним experimental решать
> >> > технологически, а не в договорном порядке.
> >> Мне не очень понятно, как "в договорном порядке" такое
> >> решать.  Питонщики должны договариваться с гномоводами,
> >> о том, когда именно они будут "ломать" experimental?
> > Да, пока это не получится сделать более fine grained.
> Как единый experimental в этом поможет? Как можно тестировать
> Питон, если разломан Гном?

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

> Это автоматически уводит от идеи dist-upgrade к идее
> выборочного install, а для таких задач у нас Daedalus вроде как
> есть.

officially unmaintained (sass@ некогда стало), в том-то и дело.
И вычистить много чего надо бы, сверив ченжлоги на предмет merged
into sisyphus.

> Или к раздельным карманам, которые можно подключать независимо
> (тут вопрос - а такое вообще возможно без риска разлома
> системы?)

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

> > кроме примера /people/gnome + gnome@.
> Угу, и вам очень хочется наладить взаимодействие многих
> мантейнеров техническими средствами, уйдя от премодерации
> к постмодерации.

Мне (лично) хочется уменьшить PITA при обычной работе над сизифом
-- заливке новых пакетов, обновлении старых, особенно библиотек
и в эквиваленте.

А то наш кукурузник потихоньку превращается в лайнер, но без
автопилота и гирокомпаса. :)

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

Re: [devel] experimental "vs" people (was: Бранчи и прочее)

[Damir Shayhutdinov]

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

> Ну это в будущем, для начала бы как ldv@ и заметил -- в качестве
> одного кармана на всех, облегчающего сломоопасные переезды,
> затрагивающие пакеты более чем одного майнтейнера.
У меня есть мнение,что "один карман на всех" делать сложнее, чем по
одному карману на каждую большую задачу. В смысле мержить в Сизиф
сложнее. Результат "суперпозиции" карманов зависит от очень многого. А
в одном большом кармане, он вообще не определен. Если в рамках shared
task еще можно как-то задать этот порядок, то в общем котле это будет
ужас.

> Понимаешь, сейчас вот icesik@ затеял переделывать prometeus.
> Общего у них как минимум потрошилка пакетов.  Если заранее
> придумать какой-то API ("хотя бы просигналить, где лежит
> разобранный пакет"), можно сэкономить что-то минут 5--15
> процессорного времени (не помню) и заметное количество i/o.
Дык в том то и проблема, что соломку можно постелить, только зная где
упасть. А заранее что-то придумывать, это большой риск не угадать
будущих проблем. Поэтому прототипы так важны.

>> Миш, вы опасаетесь, [...]
> Я хочу делать вместе так, чтобы по возможности всем было
> не хуже (и многим -- лучше).
Дык может, подумать, а нет ли лучших способов сделать то же самое?

> Мне кажется, что Дима понимает, но до всего руки заведомо не
> дойдут, а Лёша чрезмерно увлёкся математикой и порой ставит
> красоту абстракции выше людей.
Дык может не ждать, пока у них руки дойдут?

> Ещё мне кажется, что Дима не будет что-либо делать потому,
> что об этом много кричат.
Это была бы странная аргументация.

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

> officially unmaintained (sass@ некогда стало), в том-то и дело.
> И вычистить много чего надо бы, сверив ченжлоги на предмет merged
> into sisyphus.
Неужели сделать Daedalus officially maintained сложнее?

> Математически строго нет, а статистически, судя по трём месяцам
> с забытым дедалом и прочими локальными пересборками на холдах
> -- более-менее.
Я тут впервые за все время пользования Альтом поставил Сизиф на
работе. И не жалею.
Хотя конечно, сейчас наверное правильным действием будет соскочить с
Сизифа на p5. Буду еще думать. Сизиф, по-моему, стал более
стабильным,чем протухащие бранчи.

> Мне (лично) хочется уменьшить PITA при обычной работе над сизифом
> -- заливке новых пакетов, обновлении старых, особенно библиотек
> и в эквиваленте.
Я думал, SharedLibPolicy для библиотек в общем-то решает основные проблемы....

> А то наш кукурузник потихоньку превращается в лайнер, но без
> автопилота и гирокомпаса. :)
Я согласен, что нужно иметь возможность тестировать что-то до
попадания в Сизиф. И понимаю, что хочется сделать все и сразу в
шоколаде. Но так же не бывает. Давайте быть реалистами и не пытаться
откусить больше, чем способны проглотить.

Re: [devel] experimental "vs" people (was: Бранчи и прочее)

[Michael Shigorin]

On Wed, Sep 09, 2009 at 11:31:31PM +0400, Damir Shayhutdinov wrote:
> Дык в том то и проблема, что соломку можно постелить, только
> зная где упасть. А заранее что-то придумывать, это большой риск
> не угадать будущих проблем. Поэтому прототипы так важны.

Да, ты точно сформулировал то, что я пытался дописать.

> >> Миш, вы опасаетесь, [...]
> > Я хочу делать вместе так, чтобы по возможности всем было
> > не хуже (и многим -- лучше).
> Дык может, подумать, а нет ли лучших способов сделать то же самое?

Пока не придумалось.

> > Мне кажется, что Дима понимает, но до всего руки заведомо не
> > дойдут, а Лёша чрезмерно увлёкся математикой и порой ставит
> > красоту абстракции выше людей.
> Дык может не ждать, пока у них руки дойдут?

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

> > officially unmaintained (sass@ некогда стало), в том-то и
> > дело.  И вычистить много чего надо бы, сверив ченжлоги на
> > предмет merged into sisyphus.
> Неужели сделать Daedalus officially maintained сложнее?

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

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

Угу.

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

Re: [devel] experimental "vs" people (was: Бранчи и прочее)

[Денис Смирнов]

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

On Wed, Sep 09, 2009 at 11:31:31PM +0400, Damir Shayhutdinov wrote:

DS> Я думал, SharedLibPolicy для библиотек в общем-то решает основные проблемы....

Ему мало кто следует, увы.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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