[devel] ALT: Liberte, egalite, fraternite ou la Mort?

[devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Igor Vlasenko]

Уважаемые коллеги,
кто в танке, прошу обратить внимание на
бурную дискуссию в community по git.alt.

Грубо говоря, надо 
1) пояснить, что переезд на git.alt -- дело добровольное.
2) не повышать порог вхождения
Не затруднять работу тех, кто не осилил git.alt,
но умеет src.rpm, иначе вся наша тим потеряет большую
часть потенциальных участников.
3) не хватает возможности при желании откатиться -
переехать с git.alt на srpm.
4) Надо возродить backports.

Нам нужны:
и ясли -- backports
и школа -- src.rpms
и университет -- git.alt
и все это вместе.

Чтобы не было, что тим стала как ракета.
Некоторая меньшая часть сбросила предварительную 
ступень и улетела в космос для поиска в вакууме 
сферического коня, а остальные сгорели :(

Liberte, Egalite, Fraternite, ou Сизифу будет la Mort


<QUOTE>--------------------------------------
Motsyo Gennadi aka Drool пишет:
> Timur Batyrshin пишет:
>>> заниматься интимом с git.alt.
>>
>> Дык веди разработку сразу в нем. Тем более, что это удобнее.
> 
>     Мне неудобно. Плюсов для себя, кроме одного - совместная разработка
> (да и то мне это сомнительно), я не увидел. Геморроя стало больше.
> Телодвижений - тоже.

Раз пошла такая [пьянка] дискуссия - расскажите мне текущую политику
относительно git и старого incoming. Ибо за рассылками внимательно не
слежу и не в курсе ситуации.

Вот я типа майнтейнер, поддерживаю целых пять пакетов. Дела с git не
имел и, честно говоря, иметь не хочу. Коллективной разработки над моими
пакетами нет и не предвидится. Тратить день на то, чтобы разбираться с
git у меня нет ни времени, ни желания, поскольку это будет сопряжено с
чтением уймы документации и письмами в рассылку (смотри ниже).
------------------------------------------</QUOTE>

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Aleksey Novodvorsky]

26.02.09, Igor Vlasenko<vlasenko@imath.kiev.ua> написал(а):
> Уважаемые коллеги,
>  кто в танке, прошу обратить внимание на
>  бурную дискуссию в community по git.alt.
>
>  Грубо говоря, надо
>  1) пояснить, что переезд на git.alt -- дело добровольное.
>  2) не повышать порог вхождения
>  Не затруднять работу тех, кто не осилил git.alt,
>  но умеет src.rpm, иначе вся наша тим потеряет большую
>  часть потенциальных участников.
>  3) не хватает возможности при желании откатиться -
>  переехать с git.alt на srpm.
>  4) Надо возродить backports.

Хорошо бы.
2dottedmag, ldv : можно создать структуру backports? можно ли создав
ее, анонсировать в community@ и изложить 4 пункта Игоря?

Rgrds, Алексей

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Mikhail Gusarov]

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


Twas brillig at 12:02:18 26.02.2009 UTC+02 when vlasenko@imath.kiev.ua did gyre and gimble:

 IV> 2) не повышать порог вхождения Не затруднять работу тех, кто не
 IV> осилил git.alt, но умеет src.rpm, иначе вся наша тим потеряет
 IV> большую часть потенциальных участников.

Недавняя практика join (с тех пор, как там появились менторы и стало
требоваться не только собрать пакет, но и проивзаимодействовать с
ментором по поводу его заливки) показывает, что все приходящие на него
безо всякого труда за считанные дни осваивают и rpmbuild, и gear, и
git.alt.

 IV> 4) Надо возродить backports.

Давайте. Это единственный разумный вывод из всего.

-- 

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

[devel] Fwd: ALT: Liberte, egalite, fraternite ou la Mort?

[Aleksey Novodvorsky]

26.02.09, Igor Vlasenko<vlasenko@imath.kiev.ua> написал(а):

> Уважаемые коллеги,
 >  кто в танке, прошу обратить внимание на
 >  бурную дискуссию в community по git.alt.
 >
 >  Грубо говоря, надо
 >  1) пояснить, что переезд на git.alt -- дело добровольное.
 >  2) не повышать порог вхождения
 >  Не затруднять работу тех, кто не осилил git.alt,
 >  но умеет src.rpm, иначе вся наша тим потеряет большую
 >  часть потенциальных участников.
 >  3) не хватает возможности при желании откатиться -
 >  переехать с git.alt на srpm.
 >  4) Надо возродить backports.


Хорошо бы.
 2dottedmag, ldv : можно создать структуру backports? можно ли создав
 ее, анонсировать в community@ и изложить 4 пункта Игоря?

 Rgrds, Алексей

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Mikhail Gusarov]

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


Twas brillig at 13:13:53 26.02.2009 UTC+03 when a.e.nvdv@gmail.com did gyre and gimble:

 >>  3) не хватает возможности при желании откатиться -
 >>  переехать с git.alt на srpm.
 >>  4) Надо возродить backports.

 AN> 2dottedmag, ldv : можно создать структуру backports? можно ли
 AN> создав ее, анонсировать в community@ и изложить 4 пункта Игоря?

Пункта 3) не будет никогда, ибо это дискредитирует саму идею хранения
пакетов в git.

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Aleksey Novodvorsky]

26.02.09, Mikhail Gusarov<dottedmag@altlinux.org> написал(а):
>
>  Twas brillig at 12:02:18 26.02.2009 UTC+02 when vlasenko@imath.kiev.ua did gyre and gimble:
>
>   IV> 2) не повышать порог вхождения Не затруднять работу тех, кто не
>   IV> осилил git.alt, но умеет src.rpm, иначе вся наша тим потеряет
>   IV> большую часть потенциальных участников.
>
>  Недавняя практика join (с тех пор, как там появились менторы и стало
>  требоваться не только собрать пакет, но и проивзаимодействовать с
>  ментором по поводу его заливки) показывает, что все приходящие на него
>  безо всякого труда за считанные дни осваивают и rpmbuild, и gear, и
>  git.alt.

Надо сделать обучающий курс в moodle.
george@?

Rgrds, Алексей

>
>   IV> 4) Надо возродить backports.
>
>  Давайте. Это единственный разумный вывод из всего.
>
>
>  --
>
> _______________________________________________
>  Devel mailing list
>  Devel@lists.altlinux.org
>  https://lists.altlinux.org/mailman/listinfo/devel
>
>

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Grigory Batalov]

On Thu, 26 Feb 2009 12:02:18 +0200
Igor Vlasenko wrote:

> кто в танке, прошу обратить внимание на
> бурную дискуссию в community по git.alt.
> 
> Грубо говоря, надо 
> 1) пояснить, что переезд на git.alt -- дело добровольное.
> 2) не повышать порог вхождения
> Не затруднять работу тех, кто не осилил git.alt,
> но умеет src.rpm, иначе вся наша тим потеряет большую
> часть потенциальных участников.
> 3) не хватает возможности при желании откатиться -
> переехать с git.alt на srpm.
> 4) Надо возродить backports.
> 
> Нам нужны:
> и ясли -- backports
> и школа -- src.rpms
> и университет -- git.alt
> и все это вместе.
> 
> Чтобы не было, что тим стала как ракета.
> Некоторая меньшая часть сбросила предварительную 
> ступень и улетела в космос для поиска в вакууме 
> сферического коня, а остальные сгорели :(

Я считаю, каждый разработчик должен освоить хотя бы одну VCS (CVS, Subversion).
Для линуксоидов - git хороший выбор.

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Mikhail Gusarov]

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


Twas brillig at 13:21:37 26.02.2009 UTC+03 when bga@altlinux.org did gyre and gimble:

 GB> Для линуксоидов - git хороший выбор.

У него порог вхождения сильно выше того же CVS. Для casual maintainers
может оказаться непосильной нишей (хотя на практике и не оказывается,
см. выше про join).

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Mikhail Gusarov]

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


Twas brillig at 16:22:53 26.02.2009 UTC+06 when dottedmag@altlinux.org did gyre and gimble:

 MG> нишей

ношей

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Anton Farygin]

Aleksey Novodvorsky пишет:
> 26.02.09, Igor Vlasenko<vlasenko@imath.kiev.ua> написал(а):
>> Уважаемые коллеги,
>>  кто в танке, прошу обратить внимание на
>>  бурную дискуссию в community по git.alt.
>>
>>  Грубо говоря, надо
>>  1) пояснить, что переезд на git.alt -- дело добровольное.
>>  2) не повышать порог вхождения
>>  Не затруднять работу тех, кто не осилил git.alt,
>>  но умеет src.rpm, иначе вся наша тим потеряет большую
>>  часть потенциальных участников.
>>  3) не хватает возможности при желании откатиться -
>>  переехать с git.alt на srpm.
>>  4) Надо возродить backports.
> 
> Хорошо бы.
> 2dottedmag, ldv : можно создать структуру backports? можно ли создав
> ее, анонсировать в community@ и изложить 4 пункта Игоря?

Так она уже сейчас есть ... branch/4.0 и branch/4.1 - вполне себе backports.

По крайней мере, у меня - работает.. пакеты забрасываю без проблем.

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Anton Farygin]

Mikhail Gusarov пишет:
> Twas brillig at 13:13:53 26.02.2009 UTC+03 when a.e.nvdv@gmail.com did gyre and gimble:
> 
>  >>  3) не хватает возможности при желании откатиться -
>  >>  переехать с git.alt на srpm.
>  >>  4) Надо возродить backports.
> 
>  AN> 2dottedmag, ldv : можно создать структуру backports? можно ли
>  AN> создав ее, анонсировать в community@ и изложить 4 пункта Игоря?
> 
> Пункта 3) не будет никогда, ибо это дискредитирует саму идею хранения
> пакетов в git.

Он и не нужен - пакеты в git.alt собирать _проще_, чем собирать пакеты 
через incoming. Да и трафик исходящий намного меньше.

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Alexey I. Froloff]

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

* Mikhail Gusarov <dottedmag@> [090226 13:16]:
>  IV> 4) Надо возродить backports.
> Давайте. Это единственный разумный вывод из всего.
Зачем?  Основная идея backports - отсутствие
дистрибутивно-бранчевых ограничений на помещение пакетов в
репозитарий.  Это самая настоящая тупиковая ветвь эволюции, когда
переход branchN+backports -> branch(N+1) становится физически
невозможен.

Если все эти ограничения сохранить - чем это отличается от
раздачи ACL на свои пакеты в бранчах более другим людям?

-- 
Regards,
Sir Raorn.

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Aleksey Novodvorsky]

26.02.09, Mikhail Gusarov<dottedmag@altlinux.org> написал(а):
>
>  Twas brillig at 13:21:37 26.02.2009 UTC+03 when bga@altlinux.org did gyre and gimble:
>
>   GB> Для линуксоидов - git хороший выбор.
>
>  У него порог вхождения сильно выше того же CVS. Для casual maintainers
>  может оказаться непосильной нишей (хотя на практике и не оказывается,
>  см. выше про join).


Главное -- не совершать резких движений, которые свойственны многим из
нас. Это относится и к введению нового, и к полиси. Самое плохое, что
они создают совершенно ложнео впечатление высокомерия. Анонс новшеств
-- всегда праздник для того, кто его сделал и для тех, кто ждал. Но он
оборачивается разочарованием для того, кто привык к старому, особенно
если сразу же не согласовать спокойный roadmap  внедрения.
Даже мысли не допускаю, что кто-то из участников списка не в состоянии
освоить git. Но лучше все же -- постепенно, лучше создать условия для
а)неиспользования, б) обучения.

Rgrds, Алексей


>
>
>  --
>
> _______________________________________________
>  Devel mailing list
>  Devel@lists.altlinux.org
>  https://lists.altlinux.org/mailman/listinfo/devel
>
>

[devel] Fwd: ALT: Liberte, egalite, fraternite ou la Mort?

[Aleksey Novodvorsky]

26.02.09, Mikhail Gusarov<dottedmag@altlinux.org> написал(а):
 >

>  Twas brillig at 13:21:37 26.02.2009 UTC+03 when bga@altlinux.org did gyre and gimble:
 >
 >   GB> Для линуксоидов - git хороший выбор.
 >
 >  У него порог вхождения сильно выше того же CVS. Для casual maintainers
 >  может оказаться непосильной нишей (хотя на практике и не оказывается,
 >  см. выше про join).



Главное -- не совершать резких движений, которые свойственны многим из
 нас. Это относится и к введению нового, и к полиси. Самое плохое, что
 они создают совершенно ложнео впечатление высокомерия. Анонс новшеств
 -- всегда праздник для того, кто его сделал и для тех, кто ждал. Но он
 оборачивается разочарованием для того, кто привык к старому, особенно
 если сразу же не согласовать спокойный roadmap  внедрения.
 Даже мысли не допускаю, что кто-то из участников списка не в состоянии
 освоить git. Но лучше все же -- постепенно, лучше создать условия для
 а)неиспользования, б) обучения.

 Rgrds, Алексей


 >
 >
 >  --

>
 > _______________________________________________
 >  Devel mailing list
 >  Devel@lists.altlinux.org
 >  https://lists.altlinux.org/mailman/listinfo/devel
 >
 >

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Anton Farygin]

Mikhail Gusarov пишет:
> Twas brillig at 12:02:18 26.02.2009 UTC+02 when vlasenko@imath.kiev.ua did gyre and gimble:
> 
>  IV> 2) не повышать порог вхождения Не затруднять работу тех, кто не
>  IV> осилил git.alt, но умеет src.rpm, иначе вся наша тим потеряет
>  IV> большую часть потенциальных участников.
> 
> Недавняя практика join (с тех пор, как там появились менторы и стало
> требоваться не только собрать пакет, но и проивзаимодействовать с
> ментором по поводу его заливки) показывает, что все приходящие на него
> безо всякого труда за считанные дни осваивают и rpmbuild, и gear, и
> git.alt.

Всё верно. И в итоге этим пользоваться намного проще, чем собирать 
пакеты rpm'ом и rsync'ать в incoming.

> 
>  IV> 4) Надо возродить backports.
> 
> Давайте. Это единственный разумный вывод из всего.

Чем не устраивает branch ?

Или хочется contrib к branch ?

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Alexey I. Froloff]

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

* Mikhail Gusarov <dottedmag@> [090226 13:25]:
>  GB> Для линуксоидов - git хороший выбор.
> У него порог вхождения сильно выше того же CVS. Для casual maintainers
> может оказаться непосильной нишей (хотя на практике и не оказывается,
> см. выше про join).
Низкий порог вхождения рождает красноглазое коммунити. (ц)

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

-- 
Regards,
Sir Raorn.

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Aleksey Novodvorsky]

26.02.09, Alexey I. Froloff<raorn@altlinux.ru> написал(а):
> * Mikhail Gusarov <dottedmag@> [090226 13:25]:
>
> >  GB> Для линуксоидов - git хороший выбор.
>  > У него порог вхождения сильно выше того же CVS. Для casual maintainers
>  > может оказаться непосильной нишей (хотя на практике и не оказывается,
>  > см. выше про join).
>
> Низкий порог вхождения рождает красноглазое коммунити. (ц)

А высокий -- его убивает.

>
>  Мне как-то стрёмно пользоваться пакетами человека, который
>  говорит "мне некогда читать документацию - мантейнить надо".
>

Меньше обращайте внимание на слова.

Rgrds, Алексей

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Mikhail Gusarov]

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


Twas brillig at 17:38:08 26.02.2009 UTC+07 when root@mmedia2.kemsu.ru did gyre and gimble:

 R> Согласен. Но есть одно НО. Пока нет хорошей, понятной документации
 R> по git[.alt],

Хорошая, понятная документация по git и git.alt есть.

 R> и особенно по gear

gear - вещь отдельная. По нему есть справочник. Руководства нет.

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

Обучение работой с кем-то ещё - имеющий на существование способ обучения.

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Igor Vlasenko]

On Thu, Feb 26, 2009 at 01:28:06PM +0300, Anton Farygin wrote:
>> 2dottedmag, ldv : можно создать структуру backports? можно ли создав
>> ее, анонсировать в community@ и изложить 4 пункта Игоря?
>
> Так она уже сейчас есть ... branch/4.0 и branch/4.1 - вполне себе backports.
>
> По крайней мере, у меня - работает.. пакеты забрасываю без проблем.

Была :(
Буквально недавно напоролся -
залил в 4.1 поправленный ghostscript и нарвался на отлуп -
c введением acl в бранчи уже нчего так просто не залить :(

c введением acl возникла нужда в полноценных backports.


-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Anton Farygin]

REAL пишет:
> Grigory Batalov пишет:
>> Я считаю, каждый разработчик должен освоить хотя бы одну VCS (CVS, 
>> Subversion).
>> Для линуксоидов - git хороший выбор.
> 
> Согласен. Но есть одно НО. Пока нет хорошей, понятной документации по 
> git[.alt], и особенно по gear, данное требование не может быть 
> привлекательным для большинства кандидатов. Я вот это дело с грехом 
> пополам освоил только благодаря весьма и весьма сущестественному 
> содействию thresh@ и evg@, иначе бы до сих пор не знал, с какой стороны 
> к этому подойти. Правда, тут ещё осложняло ситуацию то, что я с svn 
> вообще не работал, только с cvs, но, подозреваю, что есть и те, кто 
> вообще с подобными вещами не работал, но, тем не менее, майнтайнером в 
> потенциале может быть очень хорошим.

А чем конкретнее не устраивает документация на wiki ? вроде как всё 
понятно и подробно.

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Dmitry V. Levin]

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

On Thu, Feb 26, 2009 at 04:14:13PM +0600, Mikhail Gusarov wrote:
> Twas brillig at 12:02:18 26.02.2009 UTC+02 when vlasenko@imath.kiev.ua did gyre and gimble:
> 
>  IV> 2) не повышать порог вхождения Не затруднять работу тех, кто не
>  IV> осилил git.alt, но умеет src.rpm, иначе вся наша тим потеряет
>  IV> большую часть потенциальных участников.
> 
> Недавняя практика join (с тех пор, как там появились менторы и стало
> требоваться не только собрать пакет, но и проивзаимодействовать с
> ментором по поводу его заливки) показывает, что все приходящие на него
> безо всякого труда за считанные дни осваивают и rpmbuild, и gear, и
> git.alt.
> 
>  IV> 4) Надо возродить backports.
> 
> Давайте. Это единственный разумный вывод из всего.

2aen,dottedmag: Объясните мне, каким вы видите backports.  Я не понимаю.


-- 
ldv

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[REAL]

Grigory Batalov пишет:
> Я считаю, каждый разработчик должен освоить хотя бы одну VCS (CVS, Subversion).
> Для линуксоидов - git хороший выбор.

Согласен. Но есть одно НО. Пока нет хорошей, понятной документации по 
git[.alt], и особенно по gear, данное требование не может быть 
привлекательным для большинства кандидатов. Я вот это дело с грехом 
пополам освоил только благодаря весьма и весьма сущестественному 
содействию thresh@ и evg@, иначе бы до сих пор не знал, с какой 
стороны к этому подойти. Правда, тут ещё осложняло ситуацию то, что я 
с svn вообще не работал, только с cvs, но, подозреваю, что есть и те, 
кто вообще с подобными вещами не работал, но, тем не менее, 
майнтайнером в потенциале может быть очень хорошим.

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Igor Vlasenko]

On Thu, Feb 26, 2009 at 04:14:13PM +0600, Mikhail Gusarov wrote:
>  IV> 2) не повышать порог вхождения Не затруднять работу тех, кто не
>  IV> осилил git.alt, но умеет src.rpm, иначе вся наша тим потеряет
>  IV> большую часть потенциальных участников.
> 
> Недавняя практика join (с тех пор, как там появились менторы и стало
> требоваться не только собрать пакет, но и проивзаимодействовать с
> ментором по поводу его заливки) показывает, что все приходящие на него
> безо всякого труда за считанные дни осваивают и rpmbuild, и gear, и
> git.alt.

Гм. можно медведя научить ездить на велосипеде,
но будет ли медведю от этого польза и удовольствие?

Я же цитировал, 
люди пишут - освоил, не нравится. 
"неудобно, лишние телодвижения" и т.д.
главное -- не загонять наганом в светлое будущее.

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Dmitry V. Levin]

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

On Thu, Feb 26, 2009 at 12:35:45PM +0200, Igor Vlasenko wrote:
> On Thu, Feb 26, 2009 at 01:28:06PM +0300, Anton Farygin wrote:
> >> 2dottedmag, ldv : можно создать структуру backports? можно ли создав
> >> ее, анонсировать в community@ и изложить 4 пункта Игоря?
> >
> > Так она уже сейчас есть ... branch/4.0 и branch/4.1 - вполне себе backports.
> >
> > По крайней мере, у меня - работает.. пакеты забрасываю без проблем.
> 
> Была :(
> Буквально недавно напоролся -
> залил в 4.1 поправленный ghostscript и нарвался на отлуп -
> c введением acl в бранчи уже нчего так просто не залить :(

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

> c введением acl возникла нужда в полноценных backports.

Объясните мне, что это такое?


-- 
ldv

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Igor Vlasenko]

On Thu, Feb 26, 2009 at 01:29:05PM +0300, Anton Farygin wrote:
> Он и не нужен - пакеты в git.alt собирать _проще_, чем собирать пакеты  
> через incoming. Да и трафик исходящий намного меньше.

Я согласен, что пакеты в git.alt собирать проще, 

Не понимаю, почему отсюда делается вывод, что
людей надо заставлять :(
_Если_ проще и удеобнее, значит _сами_ перейдут,
заставлять не надо.

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Mikhail Gusarov]

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


Twas brillig at 17:47:29 26.02.2009 UTC+07 when root@mmedia2.kemsu.ru did gyre and gimble:

 R> Может быть, не слежу за процессом обновления alt wiki. В районе
 R> нового года не было.

Где конкретно и чего не хватает? Без приведения конкретных примеров -
это болтание языком.

Документация по git, разумеется, НЕ находится на alt wiki, ибо git не
является проектом, разрабатываемым в рамках sisyphus.

 >> Обучение работой с кем-то ещё - имеющий на существование способ
 >> обучения.

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

Это совершенно другой вопрос.

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Timur Batyrshin]

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

On Thu, 26 Feb 2009 13:29:20 +0300
Alexey I. Froloff wrote:

> * Mikhail Gusarov <dottedmag@> [090226 13:16]:
> >  IV> 4) Надо возродить backports.
> > Давайте. Это единственный разумный вывод из всего.
> Зачем?  Основная идея backports - отсутствие
> дистрибутивно-бранчевых ограничений на помещение пакетов в
> репозитарий.  Это самая настоящая тупиковая ветвь эволюции, когда
> переход branchN+backports -> branch(N+1) становится физически
> невозможен.

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

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

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

А централизованный backports -- не совсем хорошо, т.к. все что
централизовано автоматически воспринимается надежным, если об этом
отдельно не задумываться. Хоть ты десять раз напиши красными буквами,
что репозиторий нестабильный все равно найдутся те, кто на это не
обратит внимание -- периодические вопли "случайно" обновившихся с
сизифа яркий тому пример.

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Mikhail Gusarov]

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


Twas brillig at 12:44:04 26.02.2009 UTC+02 when vlasenko@imath.kiev.ua did gyre and gimble:

 IV> Я согласен, что пакеты в git.alt собирать проще, Не понимаю, почему
 IV> отсюда делается вывод, что людей надо заставлять

Такого вывода не делается.

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[REAL]

Mikhail Gusarov пишет:
> Хорошая, понятная документация по git и git.alt есть.

Может быть, не слежу за процессом обновления alt wiki. В районе нового 
года не было.

> Обучение работой с кем-то ещё - имеющий на существование способ обучения.

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

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Motsyo Gennadi aka Drool]

Igor Vlasenko пишет:
> Гм. можно медведя научить ездить на велосипеде,
> но будет ли медведю от этого польза и удовольствие?

	+1

> Я же цитировал, 
> люди пишут - освоил, не нравится. 
> "неудобно, лишние телодвижения" и т.д.

	Мне не нравится, лишние телодвижения. Но даже я со своим вечным нытьем 
понимаю что политику партии не изменить, теперь будет git и только так. 
Этот механизм осваивать придется, если я хочу что-то дальше заливать.

> главное -- не загонять наганом в светлое будущее.

	Никто никого не загонял. Светлое будущее выстроили вокруг. Кому не 
нравится - может выйти, кому тяжело войти - может не входить.

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Alexey I. Froloff]

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

* Igor Vlasenko <vlasenko@> [090226 13:43]:
> Я же цитировал, 
> люди пишут - освоил, не нравится. 
> "неудобно, лишние телодвижения" и т.д.
Люди не так пишут.  "Посмотрел, ниасилил - многабукф".  Не
нравится только тем, не только не освоил, но и даже толком не
пытался.

-- 
Regards,
Sir Raorn.

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Eugene Ostapets]

2009/2/26 Dmitry V. Levin <ldv altlinux.org>:
> - Show quoted text -
> On Thu, Feb 26, 2009 at 04:14:13PM +0600, Mikhail Gusarov wrote:
>> Twas brillig at 12:02:18 26.02.2009 UTC+02 when vlasenko imath.kiev.ua did gyre and gimble:
>>
>>  IV> 2) не повышать порог вхождения Не затруднять работу тех, кто не
>>  IV> осилил git.alt, но умеет src.rpm, иначе вся наша тим потеряет
>>  IV> большую часть потенциальных участников.
>>
>> Недавняя практика join (с тех пор, как там появились менторы и стало
>> требоваться не только собрать пакет, но и проивзаимодействовать с
>> ментором по поводу его заливки) показывает, что все приходящие на него
>> безо всякого труда за считанные дни осваивают и rpmbuild, и gear, и
>> git.alt.
>>
>>  IV> 4) Надо возродить backports.
>>
>> Давайте. Это единственный разумный вывод из всего.
>
> 2aen,dottedmag: Объясните мне, каким вы видите backports.  Я не понимаю.
Постараюсь сформулировать свое видение backports:
0. Идея о едином backports для каждой ветки (4.0, 4.1, 5.0 и т.д.) я
считаю абсолютно бесперспективной. Если такая идея победит - можно
даже не начинать процедуру создания.
1. Backports может быть разделен на "главный", который интересен
подавляющему большинству пользователей и "по интересам."
2. В главном backports группа энтузиастов поддерживает доступность
основных десктопных компонент, т.е. openoffice.org, firefox и т.п.
Если энтузиастов для какой-то ветки нет - backports для нее не
собираются, а "главный" репозитарий удаляется.
3. "по интересам" - это тематические репозитарии, позволяющие собрать
например kde4 для Desktop 4.0.0, появляются при наличии энтузиастов и
удалятся при потере энтузиазма...
4. Основным двигателем backports может стать технология, подобная
OpenSuse Factory, которая позволяет любому заинтересованному породить
покет из группы пактов, собранный для определенной версии
дистрибутива, т.е. mini-backports. Если реализовать подобный механизм,
с поисковой системой по таким покетам и генерацией аптовых индексов,
для порождения полноценного, незамкнутого репозитария, то тренировка и
приход новых энтузиастов для ведения "главного" и "по интересам"
backports будет значительно облегчен.

Где-то так... Несогласные - могут критиковать, заинтересованные -
расширять и уточнять идею.

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Mikhail Gusarov]

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


Twas brillig at 12:39:50 26.02.2009 UTC+02 when vlasenko@imath.kiev.ua did gyre and gimble:

 IV> Я же цитировал, люди пишут - освоил, не нравится.  "неудобно,
 IV> лишние телодвижения" и т.д.

Можно ссылочки на тех, кто *освоил*?

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Eugene Ostapets]

2009/2/26 Anton Farygin <rider altlinux.com>:
> REAL пишет:
>> Согласен. Но есть одно НО. Пока нет хорошей, понятной документации по
>> git[.alt], и особенно по gear, данное требование не может быть
>> привлекательным для большинства кандидатов. Я вот это дело с грехом пополам
>> освоил только благодаря весьма и весьма сущестественному содействию thresh@
>> и evg@, иначе бы до сих пор не знал, с какой стороны к этому подойти.
>> Правда, тут ещё осложняло ситуацию то, что я с svn вообще не работал, только
>> с cvs, но, подозреваю, что есть и те, кто вообще с подобными вещами не
>> работал, но, тем не менее, майнтайнером в потенциале может быть очень
>> хорошим.
>
> А чем конкретнее не устраивает документация на wiki ? вроде как всё понятно
> и подробно.
Понятно и подробно, только для тех, кто освоил сам (много времени) или
с чужой помощью(если повезет)... Для первого просмотра для человека,
знакомого с cvs и svn - там просто непонятная абракадабра написана...
Из серии "ты сейчас на каком языке говорил" (с) анекдот.

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Andrey Rahmatullin]

On Thu, Feb 26, 2009 at 12:52:50PM +0200, Eugene Ostapets wrote:
> Для первого просмотра для человека,
> знакомого с cvs и svn - там просто непонятная абракадабра написана...
Для них есть SVN crash course.

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Igor Vlasenko]

On Thu, Feb 26, 2009 at 01:29:05PM +0300, Anton Farygin wrote:
> Mikhail Gusarov пишет:
>>  >>  3) не хватает возможности при желании откатиться -
>>  >>  переехать с git.alt на srpm.

>> Пункта 3) не будет никогда, ибо это дискредитирует саму идею хранения
>> пакетов в git.

Почему?
На самом деле, 3) есть. 
Это, в точности, происходит при заорфанивании, например.
Но это реализовано не как самостоятельная
функция, а привязано к удалению пакетов из сизифа :(

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

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

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Dmitry V. Levin]

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

On Thu, Feb 26, 2009 at 12:49:25PM +0200, Eugene Ostapets wrote:
> 2009/2/26 Dmitry V. Levin <ldv altlinux.org>:
[...]
> > 2aen,dottedmag: Объясните мне, каким вы видите backports.  Я не понимаю.
> Постараюсь сформулировать свое видение backports:
> 0. Идея о едином backports для каждой ветки (4.0, 4.1, 5.0 и т.д.) я
> считаю абсолютно бесперспективной. Если такая идея победит - можно
> даже не начинать процедуру создания.

Да, при вечно живых ветках единый backports теряет смысл.

> 1. Backports может быть разделен на "главный", который интересен
> подавляющему большинству пользователей и "по интересам."
> 2. В главном backports группа энтузиастов поддерживает доступность
> основных десктопных компонент, т.е. openoffice.org, firefox и т.п.
> Если энтузиастов для какой-то ветки нет - backports для нее не
> собираются, а "главный" репозитарий удаляется.
> 3. "по интересам" - это тематические репозитарии, позволяющие собрать
> например kde4 для Desktop 4.0.0, появляются при наличии энтузиастов и
> удалятся при потере энтузиазма...

Для такой хитрой организации потребуется release manager.  Это сильно
усложняет всю схему по сравнению с нынешним обслуживанием бранчей.

> 4. Основным двигателем backports может стать технология, подобная
> OpenSuse Factory, которая позволяет любому заинтересованному породить
> покет из группы пактов, собранный для определенной версии
> дистрибутива, т.е. mini-backports. Если реализовать подобный механизм,
> с поисковой системой по таким покетам и генерацией аптовых индексов,
> для порождения полноценного, незамкнутого репозитария, то тренировка и
> приход новых энтузиастов для ведения "главного" и "по интересам"
> backports будет значительно облегчен.

Это понятно, но это не backports, это people/<user>/ с прикрученной
сборкой и публикацией.  Вероятно, полезная возможность для тех, кто не
готов тот или иной пакет по тем или иным причинам поместить в
соответствующую ветку.


-- 
ldv

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Mikhail Gusarov]

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


Twas brillig at 12:49:25 26.02.2009 UTC+02 when eostapets@gmail.com did gyre and gimble:

 EO> 0. Идея о едином backports для каждой ветки (4.0, 4.1, 5.0 и т.д.)
 EO> я считаю абсолютно бесперспективной. Если такая идея победит -
 EO> можно даже не начинать процедуру создания.

А какие тут аргументы, кроме того, что "всё равно поставят"? Напомню,
что обновлялись до sisyphus исключительно из-за отвратительного
developer-oriented документирования, что же такое есть sisyphus, во всех
возможных местах. Это исправили, и обновляться до sisyphus пользователи
перестали.

 EO> 2. В главном backports группа энтузиастов поддерживает доступность
 EO> основных десктопных компонент, т.е. openoffice.org, firefox и т.п.
 EO> Если энтузиастов для какой-то ветки нет - backports для нее не
 EO> собираются, а "главный" репозитарий удаляется.

 EO> 3. "по интересам" - это тематические репозитарии, позволяющие
 EO> собрать например kde4 для Desktop 4.0.0, появляются при наличии
 EO> энтузиастов и удалятся при потере энтузиазма...

Тут непонятно: хуже ли протухшие backports отсутствующих? Не станет ли
наличие протухших backports очередным источником гнева "ваша *компания*
не обновляет бэкпорт!", причём обращённым не в компанию, а на community?

 EO> 4. Основным двигателем backports может стать технология, подобная
 EO> OpenSuse Factory, которая позволяет любому заинтересованному
 EO> породить покет из группы пактов, собранный для определенной версии
 EO> дистрибутива, т.е. mini-backports.

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

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Igor Vlasenko]

On Thu, Feb 26, 2009 at 12:49:25PM +0200, Eugene Ostapets wrote:
> Постараюсь сформулировать свое видение backports:
> 0. Идея о едином backports для каждой ветки (4.0, 4.1, 5.0 и т.д.) я
> считаю абсолютно бесперспективной. Если такая идея победит - можно
> даже не начинать процедуру создания.
> 1. Backports может быть разделен на "главный", который интересен
> подавляющему большинству пользователей и "по интересам."
> 2. В главном backports группа энтузиастов поддерживает доступность
> основных десктопных компонент, т.е. openoffice.org, firefox и т.п.
> Если энтузиастов для какой-то ветки нет - backports для нее не
> собираются, а "главный" репозитарий удаляется.
> 3. "по интересам" - это тематические репозитарии, позволяющие собрать
> например kde4 для Desktop 4.0.0, появляются при наличии энтузиастов и
> удалятся при потере энтузиазма...
> 4. Основным двигателем backports может стать технология, подобная
> OpenSuse Factory, которая позволяет любому заинтересованному породить
> покет из группы пактов, собранный для определенной версии
> дистрибутива, т.е. mini-backports. Если реализовать подобный механизм,
> с поисковой системой по таким покетам и генерацией аптовых индексов,
> для порождения полноценного, незамкнутого репозитария, то тренировка и
> приход новых энтузиастов для ведения "главного" и "по интересам"
> backports будет значительно облегчен.

+100

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Anton Farygin]

Eugene Ostapets пишет:
> 2009/2/26 Anton Farygin <rider altlinux.com>:
>> REAL пишет:
>>> Согласен. Но есть одно НО. Пока нет хорошей, понятной документации по
>>> git[.alt], и особенно по gear, данное требование не может быть
>>> привлекательным для большинства кандидатов. Я вот это дело с грехом пополам
>>> освоил только благодаря весьма и весьма сущестественному содействию thresh@
>>> и evg@, иначе бы до сих пор не знал, с какой стороны к этому подойти.
>>> Правда, тут ещё осложняло ситуацию то, что я с svn вообще не работал, только
>>> с cvs, но, подозреваю, что есть и те, кто вообще с подобными вещами не
>>> работал, но, тем не менее, майнтайнером в потенциале может быть очень
>>> хорошим.
>> А чем конкретнее не устраивает документация на wiki ? вроде как всё понятно
>> и подробно.
> Понятно и подробно, только для тех, кто освоил сам (много времени) или
> с чужой помощью(если повезет)... Для первого просмотра для человека,
> знакомого с cvs и svn - там просто непонятная абракадабра написана...
> Из серии "ты сейчас на каком языке говорил" (с) анекдот.

Там и этого не надо. Более того - использовать git.alt для сборки 
пакетов, можно почти не пользуясь git.
Только gear. Не хватает, пожалуй, gear-publish

Это для тех, кто не понимает. Когда разберётся - можно уже и git 
подключать, и исходники из upstream cvs дёргать и многое другое.

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Mikhail Gusarov]

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


Twas brillig at 13:56:37 26.02.2009 UTC+03 when ldv@altlinux.org did gyre and gimble:

 DVL> Да, при вечно живых ветках единый backports теряет смысл.

Ветками вопрошающие в backports пользоваться не хотят. Основные доводы:

1. Не хочу git
2. Мне нужно только 4.0, а меня заставляют бэкпортить ещё и в 4.1 и 5.0

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Anton Farygin]

Dmitry V. Levin пишет:
> On Thu, Feb 26, 2009 at 12:49:25PM +0200, Eugene Ostapets wrote:
>> 2009/2/26 Dmitry V. Levin <ldv altlinux.org>:
> [...]
<skip>
> 
> Это понятно, но это не backports, это people/<user>/ с прикрученной
> сборкой и публикацией.  Вероятно, полезная возможность для тех, кто не
> готов тот или иной пакет по тем или иным причинам поместить в
> соответствующую ветку.

Да, мне бы тоже такого хотелось.

Есть некоторые пакеты, которые либо unstable, либо testing only, либо 
вообще другого мантейнера... их можно было бы выкладывать в people/user/

В этом случае отпала бы необходимость в Daedalus, IMHO.

Вообще, не помешал бы в итоге механизм создания новых репозитариев.

Типа ssh git.alt create repo my_sisyphus based on sisyphus

С возможностью любым мантейнером выкладывать пакеты в my_sisyphus, а не 
в sisyphus.

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Anton Farygin]

Mikhail Gusarov пишет:
> Twas brillig at 13:56:37 26.02.2009 UTC+03 when ldv@altlinux.org did gyre and gimble:
> 
>  DVL> Да, при вечно живых ветках единый backports теряет смысл.
> 
> Ветками вопрошающие в backports пользоваться не хотят. Основные доводы:
> 
> 1. Не хочу git
> 2. Мне нужно только 4.0, а меня заставляют бэкпортить ещё и в 4.1 и 5.0

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

Тут давно нужно было навести порядок.

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Igor Vlasenko]

On Thu, Feb 26, 2009 at 05:01:14PM +0600, Mikhail Gusarov wrote:
> Ветками вопрошающие в backports пользоваться не хотят. Основные доводы:
> 
> 1. Не хочу git
> 2. Мне нужно только 4.0, а меня заставляют бэкпортить ещё и в 4.1 и 5.0

Да, это не абстрактные препятствия.
Я знаком с конкретными людьми, которые 
сидят на ALT и поддерживают свой RPMS.local.

Такой backports -- первый шаг к вовлечению
их в сообщество.


-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Mikhail Gusarov]

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


Twas brillig at 14:05:27 26.02.2009 UTC+03 when rider@altlinux.com did gyre and gimble:

 AF> В этом случае отпала бы необходимость в Daedalus, IMHO.

Да, в прошлый раз когда обсуждали Daedalus - на этом и сошлись, кстати.

 AF> Типа ssh git.alt create repo my_sisyphus based on sisyphus

create repo ~rider/my_sisyphus. И ACL по умолчанию владельцу выдавать.

 AF> Только, подозреваю, что это всё в итоге превратится в одну огромную
 AF> свалку...

Через год автоматом чистить :)

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Igor Vlasenko]

On Thu, Feb 26, 2009 at 04:57:06PM +0600, Mikhail Gusarov wrote:
> Эта идея бродит, в т.ч. недавно опять поднималась здесь по поводу
> бустрапа, обновления sonames и прочих крупных изменений, но относительно
> легко реализуема только в girar, против чего гневно возражают отдельные,
> эээ, особо занятые мейнтейнеры.

А кто именно возражает?
Я вроде в рассылке не встречал таких высказываний :)

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Mikhail Gusarov]

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


Twas brillig at 14:06:28 26.02.2009 UTC+03 when rider@altlinux.com did gyre and gimble:

 >> 1. Не хочу git
 >> 2. Мне нужно только 4.0, а меня заставляют бэкпортить ещё и в 4.1 и 5.0

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

Вот это наведение порядка и создало волну ненависти, способы тушения
которой мы сейчас и обсуждаем :)

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Mikhail Gusarov]

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


Twas brillig at 13:09:50 26.02.2009 UTC+02 when vlasenko@imath.kiev.ua did gyre and gimble:

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

 IV> А кто именно возражает?  Я вроде в рассылке не встречал таких
 IV> высказываний :)

Не хочу показывать пальцами. Можно прочитать в comm@ и на форуме.

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Dmitry V. Levin]

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

On Thu, Feb 26, 2009 at 05:01:14PM +0600, Mikhail Gusarov wrote:
> Twas brillig at 13:56:37 26.02.2009 UTC+03 when ldv@altlinux.org did gyre and gimble:
> 
>  DVL> Да, при вечно живых ветках единый backports теряет смысл.
> 
> Ветками вопрошающие в backports пользоваться не хотят. Основные доводы:

Не понимаю, они при этом хотят единый backports, или им просто нужен
персональный автособиратор+автопубликатор?

> 1. Не хочу git

Если они не хотят gear, то им придётся ограничиться старыми технологиями.
Если они хотят двигаться вперёд, то им придётся освоить gear хотя бы в
объёме /usr/share/doc/gear-1.5.*/QUICKSTART.ru.html

> 2. Мне нужно только 4.0, а меня заставляют бэкпортить ещё и в 4.1 и 5.0

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


-- 
ldv

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Eugene Ostapets]

2009/2/26 Dmitry V. Levin <ldv altlinux.org>:
> On Thu, Feb 26, 2009 at 12:49:25PM +0200, Eugene Ostapets wrote:
>> 2009/2/26 Dmitry V. Levin <ldv altlinux.org>:
> [...]
>> > 2aen,dottedmag: Объясните мне, каким вы видите backports.  Я не понимаю.
>> Постараюсь сформулировать свое видение backports:
>> 0. Идея о едином backports для каждой ветки (4.0, 4.1, 5.0 и т.д.) я
>> считаю абсолютно бесперспективной. Если такая идея победит - можно
>> даже не начинать процедуру создания.
>
> Да, при вечно живых ветках единый backports теряет смысл.
Даже при мертвых ветках он не имеет смысла, потому что backport
нескольких крупных кусков по сложности уживания в одном репозитарии
сравнимы с порождением нового живого бранча... Backports - возможность
получить точечное обновление наиболее критичного с точки зрения
администратора системы набора пакетов. Т.е. для десктопа - обновления
офисного инструментария, для сервера - возможно свежий
MySQL/PostgreSQL + apache. Если В рамках одного репозитария попытаться
обновлять и десктопные вещи и серверные и утрясти при этом минимальные
версии библиотек - готов новый бранч...
>
>> 1. Backports может быть разделен на "главный", который интересен
>> подавляющему большинству пользователей и "по интересам."
>> 2. В главном backports группа энтузиастов поддерживает доступность
>> основных десктопных компонент, т.е. openoffice.org, firefox и т.п.
>> Если энтузиастов для какой-то ветки нет - backports для нее не
>> собираются, а "главный" репозитарий удаляется.
>> 3. "по интересам" - это тематические репозитарии, позволяющие собрать
>> например kde4 для Desktop 4.0.0, появляются при наличии энтузиастов и
>> удалятся при потере энтузиазма...
>
> Для такой хитрой организации потребуется release manager.  Это сильно
> усложняет всю схему по сравнению с нынешним обслуживанием бранчей.
Схему управления этим должны предложить текущие энтузиасты, т.к. кроме
них никто вообще не заинтересован в появлении backports, а затем уже
остальные мантейнеры могу схему покритиковать, если планируют в ней
участвовать...
>
>> 4. Основным двигателем backports может стать технология, подобная
>> OpenSuse Factory, которая позволяет любому заинтересованному породить
>> покет из группы пактов, собранный для определенной версии
>> дистрибутива, т.е. mini-backports. Если реализовать подобный механизм,
>> с поисковой системой по таким покетам и генерацией аптовых индексов,
>> для порождения полноценного, незамкнутого репозитария, то тренировка и
>> приход новых энтузиастов для ведения "главного" и "по интересам"
>> backports будет значительно облегчен.
>
> Это понятно, но это не backports, это people/<user>/ с прикрученной
> сборкой и публикацией.  Вероятно, полезная возможность для тех, кто не
> готов тот или иной пакет по тем или иным причинам поместить в
> соответствующую ветку.
Формально может и /people/<user>, но выход туда должен быть из girar с
максимальным комфортом и контролем, что получившийся покет будет
вообще устанавливаемым. Т.е. попытка мержа в репозитарий, породит
анметы в нем, но сам карман анметов не содержит. Тут возникает
необходимость разделить репозитарий минимум на две части: main и
contrib, или даже main, universe, multiverse (пользуясь терминами
Ubuntu). Т.е. конфликт на пакеты в main недопускаются - такой покет не
публикуется, анметы на связку  main+universe не допускаются для
автоматической публикации, но теоретически должна существовать ручка
для этого. Конфликты и анметы на multiverse никого не волнуют.

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Mikhail Gusarov]

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


Twas brillig at 14:12:29 26.02.2009 UTC+03 when ldv@altlinux.org did gyre and gimble:

 >> Ветками вопрошающие в backports пользоваться не хотят. Основные
 >> доводы:

 DVL> Не понимаю, они при этом хотят единый backports, или им просто
 DVL> нужен персональный автособиратор+автопубликатор?

Единый.

 >> 1. Не хочу git

 DVL> Если они не хотят gear, то им придётся ограничиться старыми
 DVL> технологиями.  Если они хотят двигаться вперёд, то им придётся
 DVL> освоить gear хотя бы в объёме
 DVL> /usr/share/doc/gear-1.5.*/QUICKSTART.ru.html

Они не хотят двигаться вперёд. Их всё устраивает и так.

 >> 2. Мне нужно только 4.0, а меня заставляют бэкпортить ещё и в 4.1 и 5.0

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

Разумеется. Но попробуй объясни это в community@ или на форуме (где
тоже, оказывается, обитают некоторые мейнтейнеры).

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

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Dmitry V. Levin]

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

On Thu, Feb 26, 2009 at 02:05:27PM +0300, Anton Farygin wrote:
> Dmitry V. Levin пишет:
> >On Thu, Feb 26, 2009 at 12:49:25PM +0200, Eugene Ostapets wrote:
> >>2009/2/26 Dmitry V. Levin <ldv altlinux.org>:
> >[...]
> <skip>
> >
> >Это понятно, но это не backports, это people/<user>/ 
> >с прикрученной
> >сборкой и публикацией.  Вероятно, 
> >полезная возможность для тех, кто не
> >готов тот или иной пакет по тем или иным 
> >причинам поместить в
> >соответствующую ветку.
> 
> Да, мне бы тоже такого хотелось.
> 
> Есть некоторые пакеты, которые либо unstable, 
> либо testing only, либо вообще другого 
> мантейнера... их можно было бы 
> выкладывать в people/user/
> 
> В этом случае отпала бы необходимость в 
> Daedalus, IMHO.

Мне кажется, что Daedalus имеет такое же отношение к Sisyphus, как
backports к branch.  Можно назвать эти сущности Daedalus'ами, если угодно.

> Только, подозреваю, что это всё в итоге 
> превратится в одну огромную свалку...

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


-- 
ldv

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Mikhail Gusarov]

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


Twas brillig at 13:16:06 26.02.2009 UTC+02 when eostapets@gmail.com did gyre and gimble:

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

Энтузиастов бэкпортов в этом треде, кстати, не замечено.

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Eugene Ostapets]

2009/2/26 Mikhail Gusarov <dottedmag altlinux.org>:
>
> Twas brillig at 12:49:25 26.02.2009 UTC+02 when eostapets gmail.com did gyre and gimble:
>
>  EO> 0. Идея о едином backports для каждой ветки (4.0, 4.1, 5.0 и т.д.)
>  EO> я считаю абсолютно бесперспективной. Если такая идея победит -
>  EO> можно даже не начинать процедуру создания.
>
> А какие тут аргументы, кроме того, что "всё равно поставят"? Напомню,
> что обновлялись до sisyphus исключительно из-за отвратительного
> developer-oriented документирования, что же такое есть sisyphus, во всех
> возможных местах. Это исправили, и обновляться до sisyphus пользователи
> перестали.
Проблема не в "поставят"... Проблема в том, что поддерживать backports
для kde+gnome+xfce для ветки 4.0 по трудозатратам будет превышать
появление ветки 5.1, т.е. энтузиазм угаснет так же быстро, как угас в
прошлый раз...
>
>  EO> 2. В главном backports группа энтузиастов поддерживает доступность
>  EO> основных десктопных компонент, т.е. openoffice.org, firefox и т.п.
>  EO> Если энтузиастов для какой-то ветки нет - backports для нее не
>  EO> собираются, а "главный" репозитарий удаляется.
>
>  EO> 3. "по интересам" - это тематические репозитарии, позволяющие
>  EO> собрать например kde4 для Desktop 4.0.0, появляются при наличии
>  EO> энтузиастов и удалятся при потере энтузиазма...
>
> Тут непонятно: хуже ли протухшие backports отсутствующих? Не станет ли
> наличие протухших backports очередным источником гнева "ваша *компания*
> не обновляет бэкпорт!", причём обращённым не в компанию, а на community?
Так я же говорю - удаляются...

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Mikhail Gusarov]

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


Twas brillig at 13:18:53 26.02.2009 UTC+02 when eostapets@gmail.com did gyre and gimble:

 >> Тут непонятно: хуже ли протухшие backports отсутствующих? Не станет ли
 >> наличие протухших backports очередным источником гнева "ваша *компания*
 >> не обновляет бэкпорт!", причём обращённым не в компанию, а на community?
 EO> Так я же говорю - удаляются...

Ещё хуже. "Ваша *компания* пообещала нам kde4, а теперь больше ничего
нет!!! Экономите на пользователях! Мы скачали с FTP целых четыре гига
протухшего дистрибутива и остались с носом!!!"

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Igor Vlasenko]

On Thu, Feb 26, 2009 at 02:12:29PM +0300, Dmitry V. Levin wrote:
> Кто нам даст гарантию, что они не соберут в 4.0 такой пакет, который даже
> по версии-релизу нельзя будет обновить до более новых веток?  Нам эта
> гарантия важнее, чем все пакеты, которые они в в состоянии собрать.

Инфраструктура incoming/backports.

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

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Mikhail Gusarov]

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


Twas brillig at 13:24:02 26.02.2009 UTC+02 when vlasenko@imath.kiev.ua did gyre and gimble:

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

 IV> Инфраструктура incoming/backports.

Ровно эта инфраструктура уже есть. Называется branch/*. Если открутить
от него проверки, то получится backports.
-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Sergey Bolshakov]

>>>>> "Dmitry" == Dmitry V Levin <ldv-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes:
[skipped]
 > Кто нам даст гарантию, что они не соберут в 4.0 такой пакет, который даже
 > по версии-релизу нельзя будет обновить до более новых веток?  Нам эта
 > гарантия важнее, чем все пакеты, которые они в в состоянии собрать.

Браво.
Именно так.

-- 

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Dmitry V. Levin]

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

On Thu, Feb 26, 2009 at 05:16:10PM +0600, Mikhail Gusarov wrote:
> Twas brillig at 14:12:29 26.02.2009 UTC+03 when ldv@altlinux.org did gyre and gimble:
> 
>  >> Ветками вопрошающие в backports пользоваться не хотят. Основные
>  >> доводы:
> 
>  DVL> Не понимаю, они при этом хотят единый backports, или им просто
>  DVL> нужен персональный автособиратор+автопубликатор?
> 
> Единый.

Единого backports при живых ветках я себе не представляю.

>  >> 1. Не хочу git
> 
>  DVL> Если они не хотят gear, то им придётся ограничиться старыми
>  DVL> технологиями.  Если они хотят двигаться вперёд, то им придётся
>  DVL> освоить gear хотя бы в объёме
>  DVL> /usr/share/doc/gear-1.5.*/QUICKSTART.ru.html
> 
> Они не хотят двигаться вперёд. Их всё устраивает и так.

Есть проблема: нас не устраивает.

>  >> 2. Мне нужно только 4.0, а меня заставляют бэкпортить ещё и в 4.1 и 5.0
> 
>  DVL> Кто нам даст гарантию, что они не соберут в 4.0 такой пакет,
>  DVL> который даже по версии-релизу нельзя будет обновить до более новых
>  DVL> веток?  Нам эта гарантия важнее, чем все пакеты, которые они в в
>  DVL> состоянии собрать.
> 
> Разумеется. Но попробуй объясни это в community@ или на форуме (где
> тоже, оказывается, обитают некоторые мейнтейнеры).

Нет смысла объяснять мантейнерам что-либо в community@ или на форуме.
Пусть приходят сюда.

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

Переход на git/gear был анонсирован несколько лет назад.
Со всей возможной обратной совместимостью.
Если эти люди спали эти несколько лет, а сейчас придут и скажут,
что мы не хотим их ждать -- что же, пусть решают для себя сами.

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


-- 
ldv

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Eugene Ostapets]

2009/2/26 Anton Farygin <rider altlinux.com>:
>>> А чем конкретнее не устраивает документация на wiki ? вроде как всё
>>> понятно
>>> и подробно.
>>
>> Понятно и подробно, только для тех, кто освоил сам (много времени) или
>> с чужой помощью(если повезет)... Для первого просмотра для человека,
>> знакомого с cvs и svn - там просто непонятная абракадабра написана...
>> Из серии "ты сейчас на каком языке говорил" (с) анекдот.
>
> Там и этого не надо. Более того - использовать git.alt для сборки пакетов,
> можно почти не пользуясь git.
> Только gear. Не хватает, пожалуй, gear-publish
Я посмотрел после появления gear-srpmimport, помедитировал над его
результатом и выбросил, потому что для основных пакетов я использую
сборку в хостсистеме, а в хешере только проверяю целостность
buildrequires.
>
> Это для тех, кто не понимает. Когда разберётся - можно уже и git подключать,
> и исходники из upstream cvs дёргать и многое другое.
Вот когда понимание git/gear  у меня дошло до уровня автоматизации git
svn fetch с последующей сборкой получившегося,  я уже готовлюсь к
использованию girar полноценно... При этом wiki мне абсолютно ничем не
помог в организации структуры репозитариев - там просто надерганы
куски знаний вперемешку с командами... Так quickstart не пишется!


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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Eugene Ostapets]

2009/2/26 Mikhail Gusarov <dottedmag altlinux.org>:
>
> Twas brillig at 14:06:28 26.02.2009 UTC+03 when rider altlinux.com did gyre and gimble:
>
>  >> 1. Не хочу git
>  >> 2. Мне нужно только 4.0, а меня заставляют бэкпортить ещё и в 4.1 и 5.0
>
>  AF> Так это нормально... иначе они создадут массу проблем для
>  AF> пользователей при дальнейших обновлениях. Тут давно нужно было
>  AF> навести порядок.
>
> Вот это наведение порядка и создало волну ненависти, способы тушения
> которой мы сейчас и обсуждаем :)
То, как это было сделано - оно и обязано было породить волну ненависти...

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Eugene Ostapets]

2009/2/26 Mikhail Gusarov <dottedmag altlinux.org>:
>
> Twas brillig at 13:16:06 26.02.2009 UTC+02 when eostapets gmail.com did gyre and gimble:
>
>  EO> Схему управления этим должны предложить текущие энтузиасты,
>  EO> т.к. кроме них никто вообще не заинтересован в появлении backports,
>  EO> а затем уже остальные мантейнеры могу схему покритиковать, если
>  EO> планируют в ней участвовать...
>
> Энтузиастов бэкпортов в этом треде, кстати, не замечено.
Гусев вообще не прошел join и devel@ может читать только через
вебархив, а drool где-то пропадает :)
Но это не означает, что я не заинтересован в создании работающего
механизма backports :)

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Andrey Rahmatullin]

On Thu, Feb 26, 2009 at 01:27:14PM +0200, Eugene Ostapets wrote:
> Я посмотрел после появления gear-srpmimport, помедитировал над его
> результатом и выбросил, потому что для основных пакетов я использую
> сборку в хостсистеме,
И что, что в хостсистеме?

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Slava Semushin]

26 февраля 2009 г. 17:27 пользователь Eugene Ostapets <eostapets@gmail> написал:
[...]
> Я посмотрел после появления gear-srpmimport, помедитировал над его
> результатом и выбросил, потому что для основных пакетов я использую
> сборку в хостсистеме, а в хешере только проверяю целостность
> buildrequires.

Использование gear-srpmimport, насколько понимаю, не принуждает к
использованию hasher.

Признаюсь, что уже более полугода все свои пакеты собираю только в
хост-системе, с помощью hsh-rpm -bs


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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Mikhail Gusarov]

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


Twas brillig at 14:26:48 26.02.2009 UTC+03 when ldv@altlinux.org did gyre and gimble:

 DVL> Переход на git/gear был анонсирован несколько лет назад.  Со всей
 DVL> возможной обратной совместимостью.

Ok.

Кратая резолюция треда:

1. Для удобства разработки - сделать "карманы" в girar.

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

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

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Anton Farygin]

Dmitry V. Levin пишет:
> On Thu, Feb 26, 2009 at 02:05:27PM +0300, Anton Farygin wrote:
>> Dmitry V. Levin пишет:
>>> On Thu, Feb 26, 2009 at 12:49:25PM +0200, Eugene Ostapets wrote:
>>>> 2009/2/26 Dmitry V. Levin <ldv altlinux.org>:
>>> [...]
>> <skip>
>>> Это понятно, но это не backports, это people/<user>/ 
>>> с прикрученной
>>> сборкой и публикацией.  Вероятно, 
>>> полезная возможность для тех, кто не
>>> готов тот или иной пакет по тем или иным 
>>> причинам поместить в
>>> соответствующую ветку.
>> Да, мне бы тоже такого хотелось.
>>
>> Есть некоторые пакеты, которые либо unstable, 
>> либо testing only, либо вообще другого 
>> мантейнера... их можно было бы 
>> выкладывать в people/user/
>>
>> В этом случае отпала бы необходимость в 
>> Daedalus, IMHO.
> 
> Мне кажется, что Daedalus имеет такое же отношение к Sisyphus, как
> backports к branch.  Можно назвать эти сущности Daedalus'ами, если угодно.

да, именно так и есть. Но если такие дедалы делать на базе branch, то 
фактически получается backports.

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

Варианты по механизму устаревания:
- автоматом удалять, если пакеты с дедала появились в Sisyphus/branch 
(т.е. - смержили)
- хранить не более полугода, потом письма заинтересованным с просьбой 
удалить/смержить, срок неделя - потом удалять.

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Grigory Batalov]

On Thu, 26 Feb 2009 12:47:53 +0200
Motsyo Gennadi aka Drool wrote:

> > Я же цитировал, 
> > люди пишут - освоил, не нравится. 
> > "неудобно, лишние телодвижения" и т.д.
> 
> 	Мне не нравится, лишние телодвижения. Но даже я со своим вечным нытьем 
> понимаю что политику партии не изменить, теперь будет git и только так. 
> Этот механизм осваивать придется, если я хочу что-то дальше заливать.

Ещё имейте в виду, что осваивая новые технологии вы повышаете свою капитализацию
на рынке труда =)

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Alexey Rusakov]

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

В Чтв, 26/02/2009 в 14:16 +0300, Dmitry V. Levin пишет:
> > Есть некоторые пакеты, которые либо unstable, 
> > либо testing only, либо вообще другого 
> > мантейнера... их можно было бы 
> > выкладывать в people/user/
> > 
> > В этом случае отпала бы необходимость в 
> > Daedalus, IMHO.
> 
> Мне кажется, что Daedalus имеет такое же отношение к Sisyphus, как
> backports к branch.  Можно назвать эти сущности Daedalus'ами, если угодно.
+1

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

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Eugene Ostapets]

2009/2/26 Mikhail Gusarov <dottedmag altlinux.org>:
>
> Twas brillig at 13:18:53 26.02.2009 UTC+02 when eostapets gmail.com did gyre and gimble:
>
>  >> Тут непонятно: хуже ли протухшие backports отсутствующих? Не станет ли
>  >> наличие протухших backports очередным источником гнева "ваша *компания*
>  >> не обновляет бэкпорт!", причём обращённым не в компанию, а на community?
>  EO> Так я же говорю - удаляются...
>
> Ещё хуже. "Ваша *компания* пообещала нам kde4, а теперь больше ничего
> нет!!! Экономите на пользователях! Мы скачали с FTP целых четыре гига
> протухшего дистрибутива и остались с носом!!!"
Да при чем тут *компания*? Kde4 пообещает конкретный человек и
предоставит его(если осилит), но на kde 4.0.0 пользователь не
остановится, он будет просить 4.0.1, 4.0.2  и т.д., если команда
энтузиастов создастся, то эти версии будут появляться и никто не будет
ничего удалять, если не появится - 4.0.1 тоже не появится, а желающий
ставить kde 4.0.0 при текущем 4.2.1 не найдется...


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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Igor Vlasenko]

On Thu, Feb 26, 2009 at 02:26:48PM +0300, Dmitry V. Levin wrote:
> Следующим измненением, которое было анонсированное давно, будет тестовая
> пересборка (части) пакетов репозитория при обработке поступающих в
> репозиторий пакетов.  Да, это кому-то покажется неудобным, когда он не
> сможет просто так отправить в репозиторий пакет, который ломает сборку
> других пакетов.  Но мы хотим двигаться вперёд, верно?

Ой!
Это вещь правильная, но прежде чем делать
такое, нужно ее проговорить. Диавол в деталях :(

Как, например, при таком подходе бутстрапы делать?
С тем же gcc, можно ли будет провести сборку 
существенно нового gcc, не используя особых привилегий,
с правами простого майнтайнера?

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

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Eugene Ostapets]

2009/2/26 Andrey Rahmatullin <wrar altlinux.ru>:
> On Thu, Feb 26, 2009 at 01:27:14PM +0200, Eugene Ostapets wrote:
>> Я посмотрел после появления gear-srpmimport, помедитировал над его
>> результатом и выбросил, потому что для основных пакетов я использую
>> сборку в хостсистеме,
> И что, что в хостсистеме?
Я не видел никакого удобства хранении истории пакета в gear, на вики
не было описано по gear практически ничего начального уровня, а выхлоп
gear --help предполагал наличие знаний, которых на тот момент у меня
не было. Это теперь я практически не задумываясь получаю src.rpm
пакет, имею удобные механизм обновления из апстримов и т.д. ТЕПЕРЬ я
вижу преимущества gear, но я утверждаю что на вики недостаточно
информации, чтобы любой занятый мантейнер смог сходу их увидеть. Или
хотя бы после второго-третьего прочтения понять как сделать себе
УДОБНО, а не ГЕМОРРОЙНО...


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

Re: [devel] girar builder rebuild test

[Dmitry V. Levin]

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

On Thu, Feb 26, 2009 at 01:37:56PM +0200, Igor Vlasenko wrote:
> On Thu, Feb 26, 2009 at 02:26:48PM +0300, Dmitry V. Levin wrote:
> > Следующим измненением, которое было анонсированное давно, будет тестовая
> > пересборка (части) пакетов репозитория при обработке поступающих в
> > репозиторий пакетов.  Да, это кому-то покажется неудобным, когда он не
> > сможет просто так отправить в репозиторий пакет, который ломает сборку
> > других пакетов.  Но мы хотим двигаться вперёд, верно?
> 
> Ой!
> Это вещь правильная, но прежде чем делать
> такое, нужно ее проговорить. Диавол в деталях :(
> 
> Как, например, при таком подходе бутстрапы делать?
> С тем же gcc, можно ли будет провести сборку 
> существенно нового gcc, не используя особых привилегий,
> с правами простого майнтайнера?

Сборку -- да, разлом репозитория -- нет.

Как всегда, я все детали сперва примерю на себя.
Аккаунтом git_root при этом постараюсь не пользоваться, честное слово! ;)


-- 
ldv

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Mikhail Gusarov]

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


Twas brillig at 13:34:54 26.02.2009 UTC+02 when eostapets@gmail.com did gyre and gimble:

 EO> Да при чем тут *компания*? Kde4 пообещает конкретный человек и
 EO> предоставит его(если осилит)"

С точки зрения внешнего пользователя (проверено) нет никакого
конкретного человека, нет команды, нет компании, а есть абстрактный ALT
Linux.

-- 

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

Re: [devel] gear docs

[Dmitry V. Levin]

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

On Thu, Feb 26, 2009 at 01:40:20PM +0200, Eugene Ostapets wrote:
> 2009/2/26 Andrey Rahmatullin <wrar altlinux.ru>:
> > On Thu, Feb 26, 2009 at 01:27:14PM +0200, Eugene Ostapets wrote:
> >> Я посмотрел после появления gear-srpmimport, помедитировал над его
> >> результатом и выбросил, потому что для основных пакетов я использую
> >> сборку в хостсистеме,
> > И что, что в хостсистеме?
> Я не видел никакого удобства хранении истории пакета в gear, на вики
> не было описано по gear практически ничего начального уровня, а выхлоп
> gear --help предполагал наличие знаний, которых на тот момент у меня
> не было. Это теперь я практически не задумываясь получаю src.rpm
> пакет, имею удобные механизм обновления из апстримов и т.д. ТЕПЕРЬ я
> вижу преимущества gear, но я утверждаю что на вики недостаточно
> информации, чтобы любой занятый мантейнер смог сходу их увидеть. Или
> хотя бы после второго-третьего прочтения понять как сделать себе
> УДОБНО, а не ГЕМОРРОЙНО...

Тут речь идёт о документации для потенциального нового пользователя.
Не знаю, имею ли я моральное право это комментировать. ;)

У меня другой вопрос, собственной технической документации
gear(1)/gear-rules(5)/... достаточно?


-- 
ldv

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Alexey Tourbin]

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

On Thu, Feb 26, 2009 at 01:37:56PM +0200, Igor Vlasenko wrote:
> On Thu, Feb 26, 2009 at 02:26:48PM +0300, Dmitry V. Levin wrote:
> > Следующим измненением, которое было анонсированное давно, будет тестовая
> > пересборка (части) пакетов репозитория при обработке поступающих в
> > репозиторий пакетов.  Да, это кому-то покажется неудобным, когда он не
> > сможет просто так отправить в репозиторий пакет, который ломает сборку
> > других пакетов.  Но мы хотим двигаться вперёд, верно?
> 
> Ой!
> Это вещь правильная, но прежде чем делать
> такое, нужно ее проговорить. Диавол в деталях :(

Да.

Базовая идея -- не допускать никакого разлома.
То есть не брать e.g. gcc4.4, пока всё не починится.

> Как, например, при таком подходе бутстрапы делать?
> С тем же gcc, можно ли будет провести сборку 
> существенно нового gcc, не используя особых привилегий,
> с правами простого майнтайнера?

Как вариант, maintainer'у gcc придётся чинить все пакеты, которые
ломаются при сборке с новым gcc; но ему скорее всего не хватит прав
по ACL, чтобы вклиниться во все другие пакеты.

Ещё есть такая особенность, что апстримы как правило довольно быстро
чинять софт на совместимость со свежим gcc.  Это значит, что самому чинить
иногда ничего не надо, а надо прежде всего попробовать посмотреть новую
версию.  Это ставит мейнейнера gcc в ещё более непростое положение:
чинить ли ему пакеты по месту поломки или попробовать обновить на новую
версию.

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

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Eugene Ostapets]

2009/2/26 Mikhail Gusarov <dottedmag altlinux.org>:
>
> Twas brillig at 13:34:54 26.02.2009 UTC+02 when eostapets gmail.com did gyre and gimble:
>
>  EO> Да при чем тут *компания*? Kde4 пообещает конкретный человек и
>  EO> предоставит его(если осилит)"
>
> С точки зрения внешнего пользователя (проверено) нет никакого
> конкретного человека, нет команды, нет компании, а есть абстрактный ALT
> Linux.
Если о backports не допускать создания мифов, похожих на миф и Сизифе,
т.е. backports - это пользователь для пользователей, без всякой
гарантии, то и отношение будет к ним соответствующее... И тут нам
помогло, что старые backports, которые ассоциировались с ООО
Альтлинукс почили в бозе...

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

Re: [devel] gear docs

[Mikhail Gusarov]

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


Twas brillig at 14:46:48 26.02.2009 UTC+03 when ldv@altlinux.org did gyre and gimble:

 DVL> Тут речь идёт о документации для потенциального нового
 DVL> пользователя.  Не знаю, имею ли я моральное право это
 DVL> комментировать. ;)

В данном случае - для потенциального нового пользователя gear.

 DVL> У меня другой вопрос, собственной технической документации
 DVL> gear(1)/gear-rules(5)/... достаточно?

Не хватает именно tutorial. Тут у меня фантазия буксует, я не знаю, как
его можно написать.

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

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Mikhail Gusarov]

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


Twas brillig at 13:49:00 26.02.2009 UTC+02 when eostapets@gmail.com did gyre and gimble:

 EO> Если о backports не допускать создания мифов, похожих на миф и
 EO> Сизифе, т.е. backports - это пользователь для пользователей, без
 EO> всякой гарантии, то и отношение будет к ним соответствующее...

Тогда их нужно разделять как можно сильнее, и визуально, и
организационно (никаких приколов типа ALT Linux Sisyphus). Даже
обсуждать их в этом списке рассылки вредно :)

 EO> И тут нам помогло, что старые backports, которые ассоциировались с
 EO> ООО Альтлинукс почили в бозе...

А это верно.

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Alexey I. Froloff]

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

* Eugene Ostapets <eostapets@> [090226 14:45]:
> Это теперь я практически не задумываясь получаю src.rpm пакет,
> имею удобные механизм обновления из апстримов и т.д. ТЕПЕРЬ я
> вижу преимущества gear, но я утверждаю что на вики недостаточно
> информации, чтобы любой занятый мантейнер смог сходу их
> увидеть.
Ну а теперь, пока у тебя ещё свежи эти воспоминания, зайди на
wiki и напиши пару строк на эту тему.

-- 
Regards,
Sir Raorn.

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

Re: [devel] gear docs

[Eugene Ostapets]

2009/2/26 Dmitry V. Levin <ldv altlinux.org>:
> On Thu, Feb 26, 2009 at 01:40:20PM +0200, Eugene Ostapets wrote:
>> 2009/2/26 Andrey Rahmatullin <wrar altlinux.ru>:

> У меня другой вопрос, собственной технической документации
> gear(1)/gear-rules(5)/... достаточно?
Хм... в связке с led@, сидящим от меня на расстоянии одного метра -
вполне достаточно :) А вообще-то для получения имени архива, не
основанного на имени репозитария мне пришлось лезть в исходники
утилит, потому что использование макросов типа @name@ в документации
отражено слишком поверхностно и подходит только для типичного
случая...

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Eugene Ostapets]

2009/2/26 Mikhail Gusarov <dottedmag altlinux.org>:
>
> Twas brillig at 13:49:00 26.02.2009 UTC+02 when eostapets gmail.com did gyre and gimble:
>
>  EO> Если о backports не допускать создания мифов, похожих на миф и
>  EO> Сизифе, т.е. backports - это пользователь для пользователей, без
>  EO> всякой гарантии, то и отношение будет к ним соответствующее...
>
> Тогда их нужно разделять как можно сильнее, и визуально,
Это к вебдезигнерам
> и организационно (никаких приколов типа ALT Linux Sisyphus).
Это к ним же
> Даже обсуждать их в этом списке рассылки вредно :)
Пока для использования girar требуется прохождение join - больше
обсуждать негде :)

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

Re: [devel] gear docs

[Dmitry V. Levin]

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

On Thu, Feb 26, 2009 at 05:50:03PM +0600, Mikhail Gusarov wrote:
> 
> Twas brillig at 14:46:48 26.02.2009 UTC+03 when ldv@altlinux.org did gyre and gimble:
> 
>  DVL> Тут речь идёт о документации для потенциального нового
>  DVL> пользователя.  Не знаю, имею ли я моральное право это
>  DVL> комментировать. ;)
> 
> В данном случае - для потенциального нового пользователя gear.
> 
>  DVL> У меня другой вопрос, собственной технической документации
>  DVL> gear(1)/gear-rules(5)/... достаточно?
> 
> Не хватает именно tutorial. Тут у меня фантазия буксует, я не знаю, как
> его можно написать.

А этот текст
http://git.altlinux.org/people/kirill/public/?p=protva4.git;a=blob;f=levin/abstract.tex
для кого?


-- 
ldv

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Alexey Rusakov]

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

В Чтв, 26/02/2009 в 17:51 +0600, Mikhail Gusarov пишет:
> Twas brillig at 13:49:00 26.02.2009 UTC+02 when eostapets@gmail.com did gyre and gimble:
> 
>  EO> Если о backports не допускать создания мифов, похожих на миф и
>  EO> Сизифе, т.е. backports - это пользователь для пользователей, без
>  EO> всякой гарантии, то и отношение будет к ним соответствующее...
> 
> Тогда их нужно разделять как можно сильнее, и визуально, и
> организационно (никаких приколов типа ALT Linux Sisyphus). Даже
> обсуждать их в этом списке рассылки вредно :)
Про список рассылки я так понимаю, ты пошутил, в остальном согласен.
Соблазн, будучи человеком со стороны, принять то, что находится в
Сизифе, за продукцию ООО, действительно велик.

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

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

Re: [devel] gear docs

[Dmitry V. Levin]

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

On Thu, Feb 26, 2009 at 01:52:34PM +0200, Eugene Ostapets wrote:
> 2009/2/26 Dmitry V. Levin <ldv altlinux.org>:
> > On Thu, Feb 26, 2009 at 01:40:20PM +0200, Eugene Ostapets wrote:
> >> 2009/2/26 Andrey Rahmatullin <wrar altlinux.ru>:
> 
> > У меня другой вопрос, собственной технической документации
> > gear(1)/gear-rules(5)/... достаточно?
> Хм... в связке с led@, сидящим от меня на расстоянии одного метра -
> вполне достаточно :) А вообще-то для получения имени архива, не
> основанного на имени репозитария мне пришлось лезть в исходники
> утилит, потому что использование макросов типа @name@ в документации
> отражено слишком поверхностно и подходит только для типичного
> случая...

Перечитай, пожалуйста, gear-rules(5), и подтверди/опровергни
вышесказанное.


-- 
ldv

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Eugene Ostapets]

2009/2/26 Alexey I. Froloff <raorn altlinux.ru>:
> * Eugene Ostapets <eostapets@> [090226 14:45]:
>> Это теперь я практически не задумываясь получаю src.rpm пакет,
>> имею удобные механизм обновления из апстримов и т.д. ТЕПЕРЬ я
>> вижу преимущества gear, но я утверждаю что на вики недостаточно
>> информации, чтобы любой занятый мантейнер смог сходу их
>> увидеть.
> Ну а теперь, пока у тебя ещё свежи эти воспоминания, зайди на
> wiki и напиши пару строк на эту тему.
Я считаю проблемой нашей вики именно этот подход, каждый черкает про
git/gear пару строк, после озарения... Я не хочу все запутывать еще
сильнее, свои мысли я пока записываю локально, когда сподоблюсь их
вывести в последовательное изложение от простого к сложному - опробую
на одном подопытном кролике, уточню недостающую информацию и заставлю
его уже по моему тексту пройтись и записать самые свежие
впечатления... Время черкания строк прошло - нужно написать
полноценную самодостаточную документацию.

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

Re: [devel] gear docs

[Mikhail Gusarov]

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


Twas brillig at 14:56:07 26.02.2009 UTC+03 when ldv@altlinux.org did gyre and gimble:

 DVL> А этот текст
 DVL> http://git.altlinux.org/people/kirill/public/?p=protva4.git;a=blob;f=levin/abstract.tex
 DVL> для кого?

Это слишком мало, и только одна часть -- реклама.

Нужен(ны) документ(ы), показывающие следующее:

1. Как перевод рабочего процесса src.rpm+incoming -> gear+git.alt
упрощает работу мейнтейнера.
2. Каким образом осуществить этот перевод.

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

-- 

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

Re: [devel] gear docs

[Eugene Ostapets]

2009/2/26 Dmitry V. Levin <ldv altlinux.org>:
> On Thu, Feb 26, 2009 at 01:52:34PM +0200, Eugene Ostapets wrote:
>> 2009/2/26 Dmitry V. Levin <ldv altlinux.org>:
>> > On Thu, Feb 26, 2009 at 01:40:20PM +0200, Eugene Ostapets wrote:
>> >> 2009/2/26 Andrey Rahmatullin <wrar altlinux.ru>:
>>
>> > У меня другой вопрос, собственной технической документации
>> > gear(1)/gear-rules(5)/... достаточно?
>> Хм... в связке с led@, сидящим от меня на расстоянии одного метра -
>> вполне достаточно :) А вообще-то для получения имени архива, не
>> основанного на имени репозитария мне пришлось лезть в исходники
>> утилит, потому что использование макросов типа @name@ в документации
>> отражено слишком поверхностно и подходит только для типичного
>> случая...
>
> Перечитай, пожалуйста, gear-rules(5), и подтверди/опровергни
> вышесказанное.
Заметно лучше, чем было в момент, когда я разбирался, но получение строки:
tar.bz2: v@version@:gtk-xfce-engine-2 name=gtk-xfce-engine-@version@
все равно нетривиально без вспомогательной информации из других
источников, или множеством экспериментов, или самый короткий путь -
rtfs...

Т.е. техническая информация присутствует в приличном объеме, но порог
вхождения для ее восприятия слишком высок. Требуется gear-rules(1) и с
обязательным переводом на русский. :)

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

Re: [devel] gear docs

[Mikhail Gusarov]

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


Twas brillig at 18:04:07 26.02.2009 UTC+06 when dottedmag@altlinux.org did gyre and gimble:

 MG> 1. Как перевод рабочего процесса src.rpm+incoming -> gear+git.alt
 MG> упрощает работу мейнтейнера.
 MG> 2. Каким образом осуществить этот перевод.

Забыл

 3. Как изучить с нуля.

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

-- 

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

Re: [devel] gear docs

[Slava Semushin]

26 февраля 2009 г. 18:05 пользователь Eugene Ostapets <eostapets@gmail> написал:
[...]
> Требуется gear-rules(1) и с обязательным переводом на русский. :)

+1


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

Re: [devel] gear docs

[Mikhail Gusarov]

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


Twas brillig at 14:05:41 26.02.2009 UTC+02 when eostapets@gmail.com did gyre and gimble:

 EO> Т.е. техническая информация присутствует в приличном объеме, но порог
 EO> вхождения для ее восприятия слишком высок.

Да, есть полный справочник, но нет ничего больше.

 EO> Требуется gear-rules(1) с обязательным переводом на русский. :)

А это зачем?

-- 

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

Re: [devel] gear docs

[Dmitry V. Levin]

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

On Thu, Feb 26, 2009 at 02:05:41PM +0200, Eugene Ostapets wrote:
> 2009/2/26 Dmitry V. Levin <ldv altlinux.org>:
> > On Thu, Feb 26, 2009 at 01:52:34PM +0200, Eugene Ostapets wrote:
> >> 2009/2/26 Dmitry V. Levin <ldv altlinux.org>:
> >> > On Thu, Feb 26, 2009 at 01:40:20PM +0200, Eugene Ostapets wrote:
> >> >> 2009/2/26 Andrey Rahmatullin <wrar altlinux.ru>:
> >>
> >> > У меня другой вопрос, собственной технической документации
> >> > gear(1)/gear-rules(5)/... достаточно?
> >> Хм... в связке с led@, сидящим от меня на расстоянии одного метра -
> >> вполне достаточно :) А вообще-то для получения имени архива, не
> >> основанного на имени репозитария мне пришлось лезть в исходники
> >> утилит, потому что использование макросов типа @name@ в документации
> >> отражено слишком поверхностно и подходит только для типичного
> >> случая...
> >
> > Перечитай, пожалуйста, gear-rules(5), и подтверди/опровергни
> > вышесказанное.
> Заметно лучше, чем было в момент, когда я разбирался, но получение строки:
> tar.bz2: v@version@:gtk-xfce-engine-2 name=gtk-xfce-engine-@version@
> все равно нетривиально без вспомогательной информации из других
> источников, или множеством экспериментов, или самый короткий путь -
> rtfs...

Патчи приветствуются.

> Т.е. техническая информация присутствует в приличном объеме, но порог
> вхождения для ее восприятия слишком высок. Требуется gear-rules(1) и с
> обязательным переводом на русский. :)

Кто бы это мог написать? ;)


-- 
ldv

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

Re: [devel] gear docs

[Eugene Ostapets]

2009/2/26 Mikhail Gusarov <dottedmag altlinux.org>:
>
> Twas brillig at 14:56:07 26.02.2009 UTC+03 when ldv altlinux.org did gyre and gimble:
>
>  DVL> А этот текст
>  DVL> http://git.altlinux.org/people/kirill/public/?p=protva4.git;a=blob;f=levin/abstract.tex
>  DVL> для кого?
>
> Это слишком мало, и только одна часть -- реклама.
>
> Нужен(ны) документ(ы), показывающие следующее:
>
> 1. Как перевод рабочего процесса src.rpm+incoming -> gear+git.alt
> упрощает работу мейнтейнера.
> 2. Каким образом осуществить этот перевод.
>
> Смена рабочего процесса - это затрата ресурсов. Значит "приманка" должна
> быть достаточно весомой, а сопровождение переезда (учебник) должно эту
> затрату ресурсов уменьшать.
То, ради чего я предпринимал неоднократные попытки освоить git/gear -
автоматизация получения исходников из апстрима и генерация на выходе
пакета. Если опросить освоивших или пытающихся - можно составить
список "конфеток" и выбрать ответственных за описание вкуса этих
конфет :)

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

Re: [devel] gear docs

[Igor Vlasenko]

On Thu, Feb 26, 2009 at 06:08:08PM +0600, Mikhail Gusarov wrote:
>  EO> Требуется gear-rules(1) с обязательным переводом на русский. :)
> А это зачем?

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


-- 

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

Re: [devel] gear docs

[Eugene Ostapets]

2009/2/26 Mikhail Gusarov <dottedmag altlinux.org>:
>
> Twas brillig at 14:05:41 26.02.2009 UTC+02 when eostapets gmail.com did gyre and gimble:
>
>  EO> Т.е. техническая информация присутствует в приличном объеме, но порог
>  EO> вхождения для ее восприятия слишком высок.
>
> Да, есть полный справочник, но нет ничего больше.
>
>  EO> Требуется gear-rules(1) с обязательным переводом на русский. :)
>
> А это зачем?
Для снижения порога, когда ты читаешь описание неизвестной технологии
на малознакомом языке - очень тяжело понять какие моменты КЛЮЧЕВЫЕ, а
какие вода для связи различных аспектов использования. Русский
gear-rules(1) поможет понять что за технология и облегчит переход к
чтению англоязычного gear-rules(5)

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Timur Batyrshin]

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

On Thu, 26 Feb 2009 13:58:58 +0200
Eugene Ostapets wrote:

> >> Это теперь я практически не задумываясь получаю src.rpm пакет,
> >> имею удобные механизм обновления из апстримов и т.д. ТЕПЕРЬ я
> >> вижу преимущества gear, но я утверждаю что на вики недостаточно
> >> информации, чтобы любой занятый мантейнер смог сходу их
> >> увидеть.
> > Ну а теперь, пока у тебя ещё свежи эти воспоминания, зайди на
> > wiki и напиши пару строк на эту тему.
> Я считаю проблемой нашей вики именно этот подход, каждый черкает про
> git/gear пару строк, после озарения... Я не хочу все запутывать еще
> сильнее, свои мысли я пока записываю локально, когда сподоблюсь их
> вывести в последовательное изложение от простого к сложному - опробую
> на одном подопытном кролике, уточню недостающую информацию и заставлю
> его уже по моему тексту пройтись и записать самые свежие
> впечатления... Время черкания строк прошло - нужно написать
> полноценную самодостаточную документацию.

А если записать на странице с комментариями?

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

Re: [devel] gear docs

[Alexey Tourbin]

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

On Thu, Feb 26, 2009 at 02:10:29PM +0200, Igor Vlasenko wrote:
> On Thu, Feb 26, 2009 at 06:08:08PM +0600, Mikhail Gusarov wrote:
> >  EO> Требуется gear-rules(1) с обязательным переводом на русский. :)
> > А это зачем?
> 
> Я не раз и не два встречал в рассылках письма
> очень хороших людей, в т. ч. ставших майнтайнерами,
> которые упоминали, что не знают буржуйского :(

Тогда придётся писать шестерёнка-правила(1).

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Mikhail Gusarov]

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


Twas brillig at 15:12:00 26.02.2009 UTC+03 when batyrshin@ieml.ru did gyre and gimble:

 TB> А если записать на странице с комментариями?

Обычно такие заметки и правда не представляют особой ценности до их
упорядочивания. Таких "страниц с комментариями" про git и gear на wiki и
так много.

-- 

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

Re: [devel] gear docs

[Igor Vlasenko]

On Thu, Feb 26, 2009 at 03:15:18PM +0300, Alexey Tourbin wrote:
> > >  EO> Требуется gear-rules(1) с обязательным переводом на русский. :)
> > > А это зачем?
> > Я не раз и не два встречал в рассылках письма
> > очень хороших людей, в т. ч. ставших майнтайнерами,
> > которые упоминали, что не знают буржуйского :(
> 
> Тогда придётся писать шестерёнка-правила(1).

:)
Можно еще манить, как уважаемый bga@, 
что знание буржуйского увеличивает
капитализацию на рынке труда :)

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

Что-то мало выучило до сего дня :)

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Igor Vlasenko]

On Thu, Feb 26, 2009 at 02:47:23PM +0300, Alexey Tourbin wrote:
> > Ой!
> > Это вещь правильная, но прежде чем делать
> > такое, нужно ее проговорить. Диавол в деталях :(
> 
> Да.
> 
> Базовая идея -- не допускать никакого разлома.
> То есть не брать e.g. gcc4.4, пока всё не починится.

Это правильно, в большинстве случаев.
 
> > Как, например, при таком подходе бутстрапы делать?
> > С тем же gcc, можно ли будет провести сборку 
> > существенно нового gcc, не используя особых привилегий,
> > с правами простого майнтайнера?

Но нужны ясные правила для спецслучаев.
 
> Как вариант, maintainer'у gcc придётся чинить все пакеты, которые
> ломаются при сборке с новым gcc; но ему скорее всего не хватит прав
> по ACL, чтобы вклиниться во все другие пакеты.

Это не вариант :(
У нас традиционно уважаемый майнтайнер gcc выбирал
момент, когда Сизиф в анфризе, и ломал Сизиф с анонсом.
Желательно иметь поддержку такого workflow и для
пакетов поменьше, того же ant и maven.

> Это ставит мейнейнера gcc в ещё более непростое положение:
> чинить ли ему пакеты по месту поломки или попробовать обновить на новую
> версию.

Давайте из этого непростого положения мейнейнера gcc выведем
заранее :)
 
> > Чтобы не получилось так, что был анонс,
> > по анонсу были вопросы о граблях, эти вопросы остались без ответа,
> > в урочное время все дружно наступили на грабли.



> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Igor Vlasenko]

On Thu, Feb 26, 2009 at 02:27:25PM +0200, Igor Vlasenko wrote:
> Но нужны ясные правила для спецслучаев.
  
> Это не вариант :(
> У нас традиционно уважаемый майнтайнер gcc выбирал
> момент, когда Сизиф в анфризе, и ломал Сизиф с анонсом.
> Желательно иметь поддержку такого workflow и для
> пакетов поменьше, того же ant и maven.

Грубо говоря, если я обновляю gcc c 4.4.3.1 до 4.4.3.2,
то я не ожидаю, что что-то сломается,
и буду благодарен роботу за "держать, не пущать".

Но если я обновляю gcc с 2.96 до 3.3, то
я знаю заведомо и наперед, что много пакетов сломается.

Но мы хотим двигаться вперёд, верно?

Нужен механизм (обсудив в devel@) нажать большую
красную кнопку.

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Anton Farygin]

Eugene Ostapets пишет:
> 2009/2/26 Anton Farygin <rider altlinux.com>:
>>>> А чем конкретнее не устраивает документация на wiki ? вроде как всё
>>>> понятно
>>>> и подробно.
>>> Понятно и подробно, только для тех, кто освоил сам (много времени) или
>>> с чужой помощью(если повезет)... Для первого просмотра для человека,
>>> знакомого с cvs и svn - там просто непонятная абракадабра написана...
>>> Из серии "ты сейчас на каком языке говорил" (с) анекдот.
>> Там и этого не надо. Более того - использовать git.alt для сборки пакетов,
>> можно почти не пользуясь git.
>> Только gear. Не хватает, пожалуй, gear-publish
> Я посмотрел после появления gear-srpmimport, помедитировал над его
> результатом и выбросил, потому что для основных пакетов я использую
> сборку в хостсистеме, а в хешере только проверяю целостность
> buildrequires.

gear-rpm -ba --commit

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Kirill A. Shutemov]

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

On Thu, Feb 26, 2009 at 01:31:30PM +0300, Alexey I. Froloff wrote:
> * Mikhail Gusarov <dottedmag@> [090226 13:25]:
> >  GB> Для линуксоидов - git хороший выбор.
> > У него порог вхождения сильно выше того же CVS. Для casual maintainers
> > может оказаться непосильной нишей (хотя на практике и не оказывается,
> > см. выше про join).
> Низкий порог вхождения рождает красноглазое коммунити. (ц)

Именно это мне больше всего не нравится в Ruby. :(

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + ALT Linux Team, http://www.altlinux.org/

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Afanasov Dmitry]

26.02.09, Igor Vlasenko<vlasenko@imath.kiev.ua> написал(а):
> Уважаемые коллеги,
>  кто в танке, прошу обратить внимание на
>  бурную дискуссию в community по git.alt.
>
>  Грубо говоря, надо
>  1) пояснить, что переезд на git.alt -- дело добровольное.
>  2) не повышать порог вхождения
>  Не затруднять работу тех, кто не осилил git.alt,
хе, буквально в октябре я заявлял примерно то же. git.alt - именно что
университет. неделю git грыз, пока не понял, как с ним работать. а
ведь ещё условия ставили - "хочешь помощи, делай в git".

требование работать в git действительно является барьером для
замучивания пакетов. это как от новичка сразу требовать писать скрипты
на шелле, не дав командной строки :)


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

-- 
С уважением
Афанасов Дмитрий

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Anton Farygin]

Afanasov Dmitry пишет:
<skip>
> я больше скажу, некоторые пакеты обрабатываются тольков git. kernel
> тому яркий пример. зная src.rpm, но не зная git, что-то с такими
> пакетами сделать нет ну никакой возможности. хотя не, сделать можно,
> оставив потом у себя до тех пор, когда через годик git осознаешь. а
> нам это надо?

Надо. Ибо то, что будет сделано иначе - можно использовать только на 
localhost.

Особенно в случае ядра.

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Motsyo Gennadi aka Drool]

Eugene Ostapets пишет:
> а drool где-то пропадает :)

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Eugene Ostapets]

2009/2/26 Anton Farygin <rider altlinux.com>:
> Eugene Ostapets пишет:
>> Я посмотрел после появления gear-srpmimport, помедитировал над его
>> результатом и выбросил, потому что для основных пакетов я использую
>> сборку в хостсистеме, а в хешере только проверяю целостность
>> buildrequires.
>
> gear-rpm -ba --commit
Где ты был такой умный тогда... :) Сейчас я это уже знаю...

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

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

26 февраля 2009, Mikhail Gusarov написал(а):
> Twas brillig at 13:21:37 26.02.2009 UTC+03 when bga@altlinux.org did gyre
> and gimble:
>
>  GB> Для линуксоидов - git хороший выбор.
>
> У него порог вхождения сильно выше того же CVS. Для casual maintainers
> может оказаться непосильной нишей (хотя на практике и не оказывается,
> см. выше про join).
Не согласен. Для меня, как не матёрого разработчика, CVS и SVN оказались 
сложнее Git. ;)

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Motsyo Gennadi aka Drool]

Eugene Ostapets пишет:
>> А чем конкретнее не устраивает документация на wiki ? вроде как всё понятно
>> и подробно.
> Понятно и подробно, только для тех, кто освоил сам (много времени) или
> с чужой помощью(если повезет)... Для первого просмотра для человека,
> знакомого с cvs и svn - там просто непонятная абракадабра написана...
> Из серии "ты сейчас на каком языке говорил" (с) анекдот.

	+1
	Чтоб первый раз залить на git.alt я проел мозг сначала Черепанову, а 
потом Морсову. Это не смотря на любезно предоставленные Андреем урлы на 
wiki .

P.S. И - да, я никогда не имел дела ни с svn, ни с cvs. Надобности не 
было. Втягивание свежего qmmp из svn с помощью qsvn - я не считаю.

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Alexey Tourbin]

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

On Thu, Feb 26, 2009 at 02:35:54PM +0200, Igor Vlasenko wrote:
> On Thu, Feb 26, 2009 at 02:27:25PM +0200, Igor Vlasenko wrote:
> > Но нужны ясные правила для спецслучаев.
>   
> > Это не вариант :(
> > У нас традиционно уважаемый майнтайнер gcc выбирал
> > момент, когда Сизиф в анфризе, и ломал Сизиф с анонсом.
> > Желательно иметь поддержку такого workflow и для
> > пакетов поменьше, того же ant и maven.
> 
> Грубо говоря, если я обновляю gcc c 4.4.3.1 до 4.4.3.2,
> то я не ожидаю, что что-то сломается,
> и буду благодарен роботу за "держать, не пущать".
> 
> Но если я обновляю gcc с 2.96 до 3.3, то
> я знаю заведомо и наперед, что много пакетов сломается.

И что мы получим?  Новый gcc и несобирающиеся пакеты, минимум штук 200,
причем по косметическим причинам (из-за хедеров или из-за autotools).

С другой стороны, можно провести gcc4.4 в сизиф в несколько этапов.
Для этого в него придётся вставлять хаки, чтобы минимизировать число
непересобравшихся пакетов.  То есть там включить хедеры которые удалили
и отключить заморочку с main.  А потом по одному хаку отключать и иметь
дело с пакетами, которые отваливаются.  Каждый раз число пакетов будет
заметно меньше двухсот.

В общем схема странная но что делать?  gcc это не самоцель.

> Но мы хотим двигаться вперёд, верно?

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

> Нужен механизм (обсудив в devel@) нажать большую
> красную кнопку.

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Igor Vlasenko]

On Thu, Feb 26, 2009 at 04:43:03PM +0300, Alexey Tourbin wrote:
> Дьявол в деталях.  Мне кажется, что нельзя двигаться вперёд, оставляя
> после себя шлейф разломанных пакетов.  На самом деле в новейшей истории
> ни разу не удалось естественным образом достичь ситуации, когда число
> разломанных пакетов было бы на допустимом минимальном уровне (грубо
> говоря, не больше, чем несколько штук).  Всё время было много анметов
> и всё время пакеты сотнями не собирались.  И весь этот фриз когда осенью
> или весной начинают закручивать гайки это какое-то робкое гоняние с
> палкой за людьми.  И более приемлемое состояния в конечном счете
> удавалось добиться лишь за счёт удаления пакетов.

Об этом и речь.
Как это реально будет выглядеть?
Будет ли это похоже на pocket, о котором говорил Денис?

И как работать в рамках одной транзакции
с набором разных gcc 
gcc 3.3-althack1, set of fixes 1, ...gcc 3.3-althack2,... fix2,... 
gcc 3.3-althackN, fixes N ?

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Igor Vlasenko]

On Thu, Feb 26, 2009 at 03:50:45PM +0200, Igor Vlasenko wrote:
> Об этом и речь.
> Как это реально будет выглядеть?
> Будет ли это похоже на pocket, о котором говорил Денис?
> 
> И как работать в рамках одной транзакции
> с набором разных gcc 
> gcc 3.3-althack1, set of fixes 1, ...gcc 3.3-althack2,... fix2,... 
> gcc 3.3-althackN, fixes N ?

К тому же иногда реально бывает проще 
исправить 200 пакетов, даже робота написать,
чем бакпортировать поведение старой версии на новую.

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Anton Farygin]

Eugene Ostapets пишет:
> 2009/2/26 Anton Farygin <rider altlinux.com>:
>> Eugene Ostapets пишет:
>>> Я посмотрел после появления gear-srpmimport, помедитировал над его
>>> результатом и выбросил, потому что для основных пакетов я использую
>>> сборку в хостсистеме, а в хешере только проверяю целостность
>>> buildrequires.
>> gear-rpm -ba --commit
> Где ты был такой умный тогда... :) Сейчас я это уже знаю...

а ты не спрашивал...

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Eugene Ostapets]

2009/2/26 Anton Farygin <rider altlinux.com>:
> Eugene Ostapets пишет:
>>
>> 2009/2/26 Anton Farygin <rider altlinux.com>:
>>>
>>> Eugene Ostapets пишет:
>>>>
>>>> Я посмотрел после появления gear-srpmimport, помедитировал над его
>>>> результатом и выбросил, потому что для основных пакетов я использую
>>>> сборку в хостсистеме, а в хешере только проверяю целостность
>>>> buildrequires.
>>>
>>> gear-rpm -ba --commit
>>
>> Где ты был такой умный тогда... :) Сейчас я это уже знаю...
>
> а ты не спрашивал...
Тогда и без меня хватало спрашивающих, но в ответ была тишина...
Только переписка "достигших просвещения" о нюансах работы повергала
неофитов в безмолвие...
-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Alexey Tourbin]

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

On Thu, Feb 26, 2009 at 03:50:45PM +0200, Igor Vlasenko wrote:
> On Thu, Feb 26, 2009 at 04:43:03PM +0300, Alexey Tourbin wrote:
> > Дьявол в деталях.  Мне кажется, что нельзя двигаться вперёд, оставляя
> > после себя шлейф разломанных пакетов.  На самом деле в новейшей истории
> > ни разу не удалось естественным образом достичь ситуации, когда число
> > разломанных пакетов было бы на допустимом минимальном уровне (грубо
> > говоря, не больше, чем несколько штук).  Всё время было много анметов
> > и всё время пакеты сотнями не собирались.  И весь этот фриз когда осенью
> > или весной начинают закручивать гайки это какое-то робкое гоняние с
> > палкой за людьми.  И более приемлемое состояния в конечном счете
> > удавалось добиться лишь за счёт удаления пакетов.
> 
> Об этом и речь.
> Как это реально будет выглядеть?
> Будет ли это похоже на pocket, о котором говорил Денис?

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

В остальном, работать это будет, видимо, так: есть текущий статус
пересборки всех пакетов (какие пакеты не пересобираются).  Приходит
новый пакет, вычисляется новый статус пересборки (пересобираются все
зависимые пакеты).  Если пересборка каких-то пакетов сломалось, то новый
пакет по умолчанию не проходит.  Можно контролируемо допускать разлом
пересборки, примерно так же, как сейчас можно контролируемо нарушать
ACL/подтверждать NMU.  В отличие от NMU, нет ясного понимания, кто
сможет допускать разлом пересборки.  Видимо, только пользователь
girar_root; он же мейнейнер пакета gcc (получается нехорошо...).

> И как работать в рамках одной транзакции
> с набором разных gcc 
> gcc 3.3-althack1, set of fixes 1, ...gcc 3.3-althack2,... fix2,... 
> gcc 3.3-althackN, fixes N ?

Нет, никаких разных gcc в пределах одного задания не будет.
Я имел в виду подход попроще: сначала максимально забить gcc4.4 хаками,
чтобы не было поломок пакетов по косметическим причинам.  Когда новый
gcc пройдёт, собирать новые релизы gcc, в которых по одному эти хаки
отрывать, и чинить отвалившиеся пакеты.

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Michael Shigorin]

On Thu, Feb 26, 2009 at 02:52:47PM +0200, Kirill A. Shutemov wrote:
> On Thu, Feb 26, 2009 at 01:31:30PM +0300, Alexey I. Froloff wrote:
> > Низкий порог вхождения рождает красноглазое коммунити. (ц)
> Именно это мне больше всего не нравится в Ruby. :(

Сэры готовы перерешать все имеющиеся задачи или играючи пишут
на смолтоке? :)

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

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

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

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

On Thu, Feb 26, 2009 at 04:22:53PM +0600, Mikhail Gusarov wrote:

MG> У него порог вхождения сильно выше того же CVS. 

Это не правда. При использовании базового набора (на уровне
commit/pull/push/tag) его использование не сложнее чем svn/cvs. А работа с
тэгами и бранчами проще, очевиднее, понятнее и удобнее чем в svn.

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

MG> Для casual maintainers
MG> может оказаться непосильной нишей (хотя на практике и не оказывается,
MG> см. выше про join).

У git только один недостаток -- для сборки нужно знать некоторый набор
команд. Их даже _понимать_ не обязательно, хотя бы знать. И требуемые
знания во много раз легче получить и усвоить чем особенности сборки
rpm-пакета как такового.

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

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

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

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

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

On Thu, Feb 26, 2009 at 01:40:20PM +0200, Eugene Ostapets wrote:

EO> Я не видел никакого удобства хранении истории пакета в gear, на вики
EO> не было описано по gear практически ничего начального уровня, а выхлоп
EO> gear --help предполагал наличие знаний, которых на тот момент у меня
EO> не было. Это теперь я практически не задумываясь получаю src.rpm
EO> пакет, имею удобные механизм обновления из апстримов и т.д. ТЕПЕРЬ я
EO> вижу преимущества gear, но я утверждаю что на вики недостаточно
EO> информации, чтобы любой занятый мантейнер смог сходу их увидеть. Или
EO> хотя бы после второго-третьего прочтения понять как сделать себе
EO> УДОБНО, а не ГЕМОРРОЙНО...

etersoft-build-utils -- рулез.

rpmbb
rpmbs
и можно не думать в git пакет или нет.

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

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

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

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

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

On Thu, Feb 26, 2009 at 01:49:00PM +0200, Eugene Ostapets wrote:

EO> Если о backports не допускать создания мифов, похожих на миф и Сизифе,
EO> т.е. backports - это пользователь для пользователей, без всякой
EO> гарантии, то и отношение будет к ним соответствующее... И тут нам
EO> помогло, что старые backports, которые ассоциировались с ООО
EO> Альтлинукс почили в бозе...

backports плохое название. Тогда это contribs уж хотя бы.

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

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

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

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

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

On Thu, Feb 26, 2009 at 01:39:53PM +0300, Dmitry V. Levin wrote:

>> c введением acl возникла нужда в полноценных backports.
DVL> Объясните мне, что это такое?

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

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

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

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

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

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

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

On Thu, Feb 26, 2009 at 01:56:37PM +0300, Dmitry V. Levin wrote:

DVL> Это понятно, но это не backports, это people/<user>/ с прикрученной
DVL> сборкой и публикацией.  Вероятно, полезная возможность для тех, кто не
DVL> готов тот или иной пакет по тем или иным причинам поместить в
DVL> соответствующую ветку.

Если вспомнить то что недавно говорили про pocket'ы, и про желание делать
"временные разломанные репозитории" -- то это все в ту же сторону. Только
people/<user>/<pocketname>, ибо человеку может быть нужно несколько таких
репо.

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

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

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

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

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

On Thu, Feb 26, 2009 at 05:18:01PM +0600, Mikhail Gusarov wrote:

EO>> Схему управления этим должны предложить текущие энтузиасты,
EO>> т.к. кроме них никто вообще не заинтересован в появлении backports,
EO>> а затем уже остальные мантейнеры могу схему покритиковать, если
EO>> планируют в ней участвовать...
MG> Энтузиастов бэкпортов в этом треде, кстати, не замечено.

Здесь просто говоря о backports на самом деле говорили о дедале на
стероидах.

Истинные backports тоже нужны, но это отдельная тема.

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

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

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Alexey Tourbin]

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

On Thu, Feb 26, 2009 at 06:46:13PM +0300, Денис Смирнов wrote:
> On Thu, Feb 26, 2009 at 01:39:53PM +0300, Dmitry V. Levin wrote:
> 
> >> c введением acl возникла нужда в полноценных backports.
> DVL> Объясните мне, что это такое?
> 
> Это репозиторий в котором контроль качества минимален, собрать туда может
> каждый и без acl, и который по сути будет способом каждого опубликовать то
> что он хочет.
> 
> Проще говоря это либо contrib если речь идет о централизованом репо, либо
> по репо каждому в people. Последний вариант мне особенно нравится.

Консолидации работы минимум, разницы с ftp/ rsync.altlinux.org::people
минимум.

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Michael Shigorin]

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

On Thu, Feb 26, 2009 at 04:11:56PM +0300, Anton Farygin wrote:
> >я больше скажу, некоторые пакеты обрабатываются тольков git.
> >kernel тому яркий пример. зная src.rpm, но не зная git, что-то
> >с такими пакетами сделать нет ну никакой возможности. хотя не,
> >сделать можно, оставив потом у себя до тех пор, когда через
> >годик git осознаешь. а нам это надо?
> Надо. Ибо то, что будет сделано иначе - можно использовать
> только на localhost.  Особенно в случае ядра.

Кто из нас родился матёрым разработчиком?  Учиться тоже надо.

Предлагаюсь в уже заметно испорченные, но всё-таки кролики :)
Кто возьмётся терпеливо рассказать мне, как перетащить, скажем,
xmms в gear?

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

[-- Attachment #2: isofs-noexec-2.2.5.diff --]
[-- Type: text/plain, Size: 947 bytes --]

--- linux-2.2.5/fs/isofs/inode.c.orig	Tue Dec 29 21:40:35 1998
+++ linux-2.2.5/fs/isofs/inode.c	Mon Jul 19 21:46:48 1999
@@ -286,7 +286,7 @@
 	popt->unhide = 'n';
 	popt->check = 'u';		/* unset */
 	popt->blocksize = 1024;
-	popt->mode = S_IRUGO | S_IXUGO; /* r-x for all.  The disc could
+	popt->mode = S_IRUGO/* | S_IXUGO*/; /* r-x for all.  The disc could
 					   be shared with DOS machines so
 					   virtually anything could be
 					   a valid executable. */
@@ -1096,8 +1096,8 @@
 		for(i=0; i< raw_inode->name_len[0]; i++)
 			if(raw_inode->name[i]=='.' || raw_inode->name[i]==';')
 				break;
-		if(i == raw_inode->name_len[0] || raw_inode->name[i] == ';')
-			inode->i_mode |= S_IXUGO; /* execute permission */
+//		if(i == raw_inode->name_len[0] || raw_inode->name[i] == ';')
+//			inode->i_mode |= S_IXUGO; /* execute permission */
 	}
 	inode->i_uid = inode->i_sb->u.isofs_sb.s_uid;
 	inode->i_gid = inode->i_sb->u.isofs_sb.s_gid;

[devel] задания и схемы совместной работы

[Alexey Tourbin]

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

On Thu, Feb 26, 2009 at 03:50:45PM +0200, Igor Vlasenko wrote:
> On Thu, Feb 26, 2009 at 04:43:03PM +0300, Alexey Tourbin wrote:
> > Дьявол в деталях.  Мне кажется, что нельзя двигаться вперёд, оставляя
> > после себя шлейф разломанных пакетов.  На самом деле в новейшей истории
> > ни разу не удалось естественным образом достичь ситуации, когда число
> > разломанных пакетов было бы на допустимом минимальном уровне (грубо
> > говоря, не больше, чем несколько штук).  Всё время было много анметов
> > и всё время пакеты сотнями не собирались.  И весь этот фриз когда осенью
> > или весной начинают закручивать гайки это какое-то робкое гоняние с
> > палкой за людьми.  И более приемлемое состояния в конечном счете
> > удавалось добиться лишь за счёт удаления пакетов.
> 
> Об этом и речь.
> Как это реально будет выглядеть?
> Будет ли это похоже на pocket, о котором говорил Денис?

Я не знаю, что такое pocket, это не было строго описано.
Изначальные идеи были следующие.

1) Есть задания.  Задание содержит упорядоченный набор пакетов
для сборки.  Пересечений между пакетами в одном задании быть не
должно.  Задание применяется транзакционно, если оно не ухудшает
характеристик репозитария.

2) Совместная работа над заданиями.  Требование, чтобы задание не
ухудшало характеристик репозитария, это требование иногда означает,
что в задание вовлечены несколько человек (если пакеты одного человека
влияют на пакеты другого человека).

Есть следующие схемы совместной работы.

2.1) Человек A чинит чужие пакеты человека B и добавляет их в свое
задание (со своим тагом).  Это схема с подтверждением NMU.

2.2) Человек A просит человека B добавить исправленные пакеты
в задание человека A (таг должен поставить человек B).  Это схема
shared task.

2.3) Человек A просит человека B подписать таг у исправленного пакета,
но при этом человек A сам добавляет в своё задание исправленный таг,
подписанный человеком B.  После консультации с ldv мы от этой схемы
решили отказаться, потому что она нарушает принцип "отправлять на сборку
можно только свои собственные таги".

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

Какие ещё схемы можно придумать, чтобы людям было проще договориться?

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Sergey Bolshakov]

>>>>> "Uox3rIn2DAYQ" == Uox3rIn2DAYQ  <mithraen-u2l5PoMzF> writes:

 > On Thu, Feb 26, 2009 at 01:39:53PM +0300, Dmitry V. Levin wrote:
 >>> c введением acl возникла нужда в полноценных backports.
 DVL> Объясните мне, что это такое?

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

Непонятно только, почему на таковых исканиях-метаниях необходимо
задействовать инфраструктуру проекта sisyphus -- ей определённо
найдутся лучшие применения. В конце концов, интернет, говорят,
есть не только в дефолт-сити, и в нём полно места.

-- 

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Alexey I. Froloff]

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

* Michael Shigorin <mike@> [090226 19:08]:
> Кто возьмётся терпеливо рассказать мне, как перетащить, скажем,
> xmms в gear?
rm -rf xmms*

-- 
Regards,
Sir Raorn.

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Mikhail Gusarov]

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


Twas brillig at 19:10:53 26.02.2009 UTC+03 when sbolshakov@altlinux.ru did gyre and gimble:

 SB> Непонятно только, почему на таковых исканиях-метаниях необходимо
 SB> задействовать инфраструктуру проекта sisyphus -- ей определённо
 SB> найдутся лучшие применения.

Я вижу только один повод "за": желающие таких "backports" не умеют и не
могут самостоятельно оповестить желающих пользоваться такими "backports"
о том, что такие "backports" существуют.

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

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

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Alexey Gladkov]

Michael Shigorin wrote:
> Кто возьмётся терпеливо рассказать мне, как перетащить, скажем,
> xmms в gear?

Я могу.

-- 
Rgrds, legion

[devel] backports und branches (was: ALT: Liberte, egalite, fraternite ou la Mort?)

[Michael Shigorin]

On Thu, Feb 26, 2009 at 06:57:47PM +0300, Alexey Tourbin wrote:
> > >> c введением acl возникла нужда в полноценных backports.
> > DVL> Объясните мне, что это такое?
> > Это репозиторий в котором контроль качества минимален,
> > собрать туда может каждый и без acl, и который по сути будет
> > способом каждого опубликовать то что он хочет.
> > Проще говоря это либо contrib если речь идет о
> > централизованом репо, либо по репо каждому в people.
> > Последний вариант мне особенно нравится.
> Консолидации работы минимум

Это не так.

> разницы с ftp/ rsync.altlinux.org::people минимум.

Это тем более не так.

PS: майнтейнер backports вовсе не прочь, чтоб его заменили
скриптом, но также считает, что с введением:
 * acl в бранчах
 * требования по версиям относительно сизифа
-- работа внешних по отношению ко всяким ООО людей может
практически прекратиться.  Уж больно много сложностей.

Про ACL мне лично непонятно совсем, про версии -- понятно
в меру того, что у меня сизиф есть и используется, равно как
и _множество_ бранчей на его основе (а не один конкретный).

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

On Thu, Feb 26, 2009 at 07:10:53PM +0300, Sergey Bolshakov wrote:
> >>> c введением acl возникла нужда в полноценных backports.
> DVL> Объясните мне, что это такое?
> > Это репозиторий в котором контроль качества минимален,
> > собрать туда может каждый и без acl, и который по сути будет
> > способом каждого опубликовать то что он хочет.

Не совсем так.

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

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

Слушай, собственник -- эта инфраструктура не твоя личная.
Прекрати выдавать своё маргинальное мнение по этому вопросу
за разумное. :)

2 devel: я знаю ровно двоих активных сторонников ACL:
sbolshakov@ и legion@.  Всё.  Активных противников знаю
минимум столько же (slava@ и led@).  Сам считаю, что ACL
нужны, но с другим дефолтом -- когда "маркировка территории"
является бременем желающего её "охранять", а не производится
автоматически.

> В конце концов, интернет, говорят, есть не только 
> в дефолт-сити, и в нём полно места.

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

Если я админ и мне в первую очередь интересно, чтоб работало
в используемом бранче -- это надо ценить, _объясняя_, что
попадание моих наработок в сизиф есть залог того, что в следующем
дистрибутиве всё нужное будет [работать] из коробки.  Но не
насиловать меня разработческим ярмом.

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Michael Shigorin]

On Thu, Feb 26, 2009 at 10:16:48PM +0600, Mikhail Gusarov wrote:
> > Непонятно только, почему на таковых исканиях-метаниях
> > необходимо задействовать инфраструктуру проекта sisyphus --
> > ей определённо найдутся лучшие применения.
> Я вижу только один повод "за": желающие таких "backports"
> не умеют и не могут самостоятельно оповестить желающих
> пользоваться такими "backports" о том, что такие "backports"
> существуют.

Миш, если б ты пользовался сизифом давно и всерьёз -- знал бы,
что существенная его часть _и так_ уже размазана по people и
вообще своим нычкам и таким образом -- практически недостижима.

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

По поводу повода -- сделай rpm -qp --lastchange *.rpm по
RPMS.backports и опять же подумай ещё :)

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Mikhail Gusarov]

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


Twas brillig at 18:26:42 26.02.2009 UTC+02 when mike@osdn.org.ua did gyre and gimble:

 >> Я вижу только один повод "за": желающие таких "backports" не умеют и
 >> не могут самостоятельно оповестить желающих пользоваться такими
 >> "backports" о том, что такие "backports" существуют.

 MS> Миш, если б ты пользовался сизифом давно и всерьёз -- знал бы, что
 MS> существенная его часть _и так_ уже размазана по people и вообще
 MS> своим нычкам и таким образом -- практически недостижима.

don't blame the messenger!

-- 

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

[devel] [JT] бесплатные советы

[Michael Shigorin]

On Thu, Feb 26, 2009 at 07:13:43PM +0300, Alexey I. Froloff wrote:
> > Кто возьмётся терпеливо рассказать мне, как перетащить,
> > скажем, xmms в gear?
> rm -rf xmms*

echo 'score "~f 'raorn@'" =0' >> ~/.mutt/score

PS: я иногда не отправляю написанные письма.

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

Re: [devel] backports und branches

[Sergey Bolshakov]

>>>>> "Michael" == Michael Shigorin <mike-nVB1ZwtFQf3sG83rWm+8vg@public.gmane.org> writes:
[skipped]

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

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

 > 2 devel: я знаю ровно двоих активных сторонников ACL:
 > sbolshakov@ и legion@.  Всё.  Активных противников знаю
 > минимум столько же (slava@ и led@).  Сам считаю, что ACL
 > нужны, но с другим дефолтом -- когда "маркировка территории"
 > является бременем желающего её "охранять", а не производится
 > автоматически.
Я сторонник персональной ответственности, acl -- способ.

 >> В конце концов, интернет, говорят, есть не только 
 >> в дефолт-сити, и в нём полно места.

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

 > Если я админ и мне в первую очередь интересно, чтоб работало
 > в используемом бранче -- это надо ценить, _объясняя_, что
 > попадание моих наработок в сизиф есть залог того, что в следующем
 > дистрибутиве всё нужное будет [работать] из коробки.  Но не
 > насиловать меня разработческим ярмом.

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

-- 

[devel] пример: collectd

[Michael Shigorin]

On Thu, Feb 26, 2009 at 06:44:08PM +0300, Денис Смирнов wrote:
> EO> Если о backports не допускать создания мифов, похожих на миф и Сизифе,
> EO> т.е. backports - это пользователь для пользователей, без всякой
> EO> гарантии, то и отношение будет к ним соответствующее... И тут нам
> EO> помогло, что старые backports, которые ассоциировались с ООО
> EO> Альтлинукс почили в бозе...

Слышь, мифолог, я их вообще-то хоть раз в месяц да собираю и публикую!
Главное, сидит же напротив и хоть бы спросил :)

> backports плохое название. Тогда это contribs уж хотя бы.

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

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

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

Ну вот и сидите на старье или ищите, где оно у меня выложено.
:]

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

Re: [devel] пример: collectd

[Mikhail Gusarov]

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


Twas brillig at 18:44:35 26.02.2009 UTC+02 when mike@osdn.org.ua did gyre and gimble:

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

В этом случае я становлюсь категорическим противником
неперсонализированных бэкпортов. Как и Дедала.

Т.е. backports/daedalus - это "свежие версии"/"экспериментальная ветка",
и ничего другого.

Иная точка зрения - в people.a.o (облагороженном, с индексами и ты ды),
либо в альтернативном наборе пакетов с другими названиями
(дифференцированными не по имени человека, а по отличающейся
функциональности), но не в том же пакете с другой версией.

В остальном - согласен.

-- 

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

Re: [devel] backports und branches

[Michael Shigorin]

On Thu, Feb 26, 2009 at 07:42:52PM +0300, Sergey Bolshakov wrote:
>  >> Непонятно только, почему на таковых исканиях-метаниях
>  >> необходимо задействовать инфраструктуру проекта sisyphus --
>  >> ей определённо найдутся лучшие применения.
>  > Слушай, собственник -- эта инфраструктура не твоя личная.
>  > Прекрати выдавать своё маргинальное мнение по этому вопросу
>  > за разумное. :)
> Ой, ну да, я забыл предварить строчкой 'по моему
> (маргинальному) мнению', хотя, ээ, стой, разве я был замечен
> в высказывании мнений, не подходящих под ?

Ниже.

>  > 2 devel: я знаю ровно двоих активных сторонников ACL:
>  > sbolshakov@ и legion@.  Всё.  Активных противников знаю
>  > минимум столько же (slava@ и led@).  Сам считаю, что ACL
>  > нужны, но с другим дефолтом -- когда "маркировка территории"
>  > является бременем желающего её "охранять", а не производится
>  > автоматически.
> Я сторонник персональной ответственности, acl -- способ.

Я уже натыкался на проблемы с тем, что ты (опытный человек)
чего-то не учитывал, а вылазило это в самый неподходящий момент
(например, на стенде в декабре 2007, когда мы с led@ срочно
чинили pulseaudio, взаимодействовать по которому он с тех пор
с тобой отказался, как и icesik@, которого тоже к тому пытался
сподвигнуть).

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

С legion@ и ldv@ это тоже обсуждалось, причём в итоге для меня
ACL в бранчах стали полной неожиданностью: Terminal 4.0 я бы так
попросту не смог выпустить, ну или требовать себе этакий suid.
Который мне не нужен.

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

Не-а, в море много траулеров.  Рыба становится ценностью,
а мы её не разводим, но пытаемся просеивать через ещё более
крупное сито.  Надо быть очень уютным местом, чтоб это работало.

> > Если я админ и мне в первую очередь интересно, чтоб работало
> > в используемом бранче -- это надо ценить, _объясняя_, что
> > попадание моих наработок в сизиф есть залог того, что в
> > следующем дистрибутиве всё нужное будет [работать] из
> > коробки.  Но не насиловать меня разработческим ярмом.
> Ну так в семестр нужно учиться, а пакеты готовить смолоду^W
> загодя, внятно объясняя верблюду с горбом и ярмом, что же от
> него требуется -- способы есть.

Серж, я сейчас админ.  Ты о каком семестре? :)

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

Вот я бы сейчас пакеты led@ поправил в M50 и мож уже собирал
потихоньку Terminal 5.0, а так всё руки не доходят его подёргать.
Ему же этот M50 нафиг не упал, как понимаю.

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

Re: [devel] пример: collectd

[Michael Shigorin]

On Thu, Feb 26, 2009 at 10:49:07PM +0600, Mikhail Gusarov wrote:
>  MS> бэкпорты могут быть выражением иной точки зрения,
>  MS> чем представленная в бранче (такое случалось).
> В этом случае я становлюсь категорическим противником
> неперсонализированных бэкпортов. Как и Дедала.

Думаю, их контрибуторов, майнтейнеров и пользователей это не волнует.
:)

> Т.е. backports/daedalus - это "свежие версии"/"экспериментальная ветка",
> и ничего другого.

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

У меня вот в apache-1.3 такой форк внутри издревле живёт --
со статическим mod_perl и без него.  Потому как DSO течёт под
нагрузкой и это не лечится.

А если б пакет поддерживал человек, который считает, что mod_perl
не нужен, например?

> Иная точка зрения - в people.a.o (облагороженном, с индексами и ты ды),

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

Надо будет порыть, насколько (не)эффективны LP-шные PPA...

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

До этого тоже периодически доходит (или почти доходит),
тоже плохо.

> В остальном - согласен.

Спасибо.

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

Re: [devel] пример: collectd

[Mikhail Gusarov]

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


Twas brillig at 19:07:03 26.02.2009 UTC+02 when mike@osdn.org.ua did gyre and gimble:

 MS> Думаю, их контрибуторов, майнтейнеров и пользователей это не
 MS> волнует :)

Ну так как я потенциально мейнтейню прометей - таки-должно.

 >> Т.е. backports/daedalus - это "свежие версии"/"экспериментальная
 >> ветка", и ничего другого.

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

Именно apache и apache-staticmodperl. Как ещё? Это же совершенно
очевидно и тривиально.

Если мейнтейнер (абстрактно говоря) apache некооперативен - собираемые
из двух source-пакетов.

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

-- 

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

Re: [devel] пример: collectd

[Mikhail Gusarov]

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


Twas brillig at 19:16:55 26.02.2009 UTC+02 when mike@osdn.org.ua did gyre and gimble:

 >>  MS> Ты никогда не размышлял над пакетом, который можно собрать
 >>  MS> действительно по-разному и нет однозначно подходящего варианта?
 >> Именно apache и apache-staticmodperl. Как ещё? Это же совершенно
 >> очевидно и тривиально.

 MS> Бинарные apache и apache-mod_perl, исходный тут один (apache).

apache, apache-mod_perl и apache-staticmod_perl. Ну или как там
ещё. Идея состоит в том, что все пакеты лежат в одном репозитории и
видны невооружённым гуглом взглядом.

 >> Если мейнтейнер (абстрактно говоря) apache некооперативен -
 >> собираемые из двух source-пакетов.

 MS> Вот такого и пытаюсь избегать, а не потакать.

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

 MS> Эту банку форков открывать совершенно не стоит.

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

 >> Abuse-ить альтернативный репозиторий только для этого и вносить
 >> какие-то совершенно непредсказуемые изменения в в разных версиях
 >> одинаково называющихся пакетов просто не имеет смысла.

 MS> Ради такого -- нет, но кто знает, что бы было, если б это изменение
 MS> пришлось делать уже у нас, а не брать из mdk...

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

P.S: возвращаю в devel. Эту глупость необходимо доковырять до конца, а
не загонять под ковёр.

-- 

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

Re: [devel] backports und branches

[Sergey Bolshakov]

>>>>> "Michael" == Michael Shigorin <mike-nVB1ZwtFQf3sG83rWm+8vg@public.gmane.org> writes:
[skipped]

 > Я уже натыкался на проблемы с тем, что ты (опытный человек)
 > чего-то не учитывал, а вылазило это в самый неподходящий момент
 > (например, на стенде в декабре 2007, когда мы с led@ срочно
 > чинили pulseaudio, взаимодействовать по которому он с тех пор
 > с тобой отказался, как и icesik@, которого тоже к тому пытался
 > сподвигнуть).
Ну вы починили ? Надеюсь, да.
Так какого же рожна я до сих пор слабо представляю, что же там
ломалось и совсем не представляю, как починилось ?
Это тем более удивительно, что у меня есть опыт конструктивного
взаимодействия с led@ по другим пакетам.

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

 > С legion@ и ldv@ это тоже обсуждалось, причём в итоге для меня
 > ACL в бранчах стали полной неожиданностью: Terminal 4.0 я бы так
 > попросту не смог выпустить, ну или требовать себе этакий suid.
 > Который мне не нужен.
Это твоя проблема или проблема сизифа -- я не расслышал, извини.

[skipped]

 >> > Если я админ и мне в первую очередь интересно, чтоб работало
 >> > в используемом бранче -- это надо ценить, _объясняя_, что
 >> > попадание моих наработок в сизиф есть залог того, что в
 >> > следующем дистрибутиве всё нужное будет [работать] из
 >> > коробки.  Но не насиловать меня разработческим ярмом.
 >> Ну так в семестр нужно учиться, а пакеты готовить смолоду^W
 >> загодя, внятно объясняя верблюду с горбом и ярмом, что же от
 >> него требуется -- способы есть.

 > Серж, я сейчас админ.  Ты о каком семестре? :)
Я о том, что приложить усилия следовало бы к выправлению, увы,
типичной ситуации, когда хорошия мысля приходят опосля, бишь, после
того, когда до всех заинтересованных доходит, что вот это и то, уже
отбранчёванное, нужно равнять не то что напильниками -- пожарными
баграми, иначе вообще никак и никуда.
Чините, репортите, ругайтесь, пока маленькое и в сизифе --
не нужно будет убиваться о ACL'и в бранчах потом.

-- 

Re: [devel] backports und branches

[Mikhail Gusarov]

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


Twas brillig at 20:30:03 26.02.2009 UTC+03 when sbolshakov@altlinux.ru did gyre and gimble:

 >> С legion@ и ldv@ это тоже обсуждалось, причём в итоге для меня ACL в
 >> бранчах стали полной неожиданностью: Terminal 4.0 я бы так попросту
 >> не смог выпустить, ну или требовать себе этакий suid.  Который мне
 >> не нужен.

 SB> Это твоя проблема или проблема сизифа -- я не расслышал, извини.

Если честно - конкретно это является проблемой ООО :)

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

Это не всегда возможно.

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

Опять pocket, с теми же проверками, что и на бранчах, минус ACL, но уже
для разработки дистрибутива?

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Anton Farygin]

Michael Shigorin пишет:
> On Thu, Feb 26, 2009 at 04:11:56PM +0300, Anton Farygin wrote:
>>> я больше скажу, некоторые пакеты обрабатываются тольков git.
>>> kernel тому яркий пример. зная src.rpm, но не зная git, что-то
>>> с такими пакетами сделать нет ну никакой возможности. хотя не,
>>> сделать можно, оставив потом у себя до тех пор, когда через
>>> годик git осознаешь. а нам это надо?
>> Надо. Ибо то, что будет сделано иначе - можно использовать
>> только на localhost.  Особенно в случае ядра.
> 
> Кто из нас родился матёрым разработчиком?  Учиться тоже надо.
> 
> Предлагаюсь в уже заметно испорченные, но всё-таки кролики :)
> Кто возьмётся терпеливо рассказать мне, как перетащить, скажем,
> xmms в gear?

Ну, если очень нужно - то и я могу рассказать. Welcome то мой Jabber.

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Alexey Tourbin]

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

On Thu, Feb 26, 2009 at 12:02:18PM +0200, Igor Vlasenko wrote:
> Грубо говоря, надо 
> 1) пояснить, что переезд на git.alt -- дело добровольное.

Сейчас src.rpm пакеты конвертируются из incoming в git.alt.

Это дело добровольное до тех пор, пока не возникнет сложных
коллизий (когда потребуется комплектовать транзакцию сложным
набором пакетов).  В сложных случаях -- либо переезд на git.alt,
либо advanced логика совмещения gear-репозитариев и src.rpm пакетов.

> 2) не повышать порог вхождения

Почему нет?  Эгалитаризм, вынесенный в заголовок, -- это противоположно
хакерству как истоку free software.

> Не затруднять работу тех, кто не осилил git.alt,
> но умеет src.rpm, иначе вся наша тим потеряет большую
> часть потенциальных участников.

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

> 3) не хватает возможности при желании откатиться -
> переехать с git.alt на srpm.

В исключительных случаях считайте что такая возможность есть.
А штатно конечно такой возможности нет, иначе зачем всё делается.

> 4) Надо возродить backports.

А также всё, что потребуется впредь.

Бекпорты это вообще глупость какая-то.  Если сбекпортить все пакеты,
то получится Sisyphus, только намного хуже.

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

Re: [devel] пример: collectd

[Mikhail Gusarov]

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


Twas brillig at 19:07:03 26.02.2009 UTC+02 when mike@osdn.org.ua did gyre and gimble:

 MS> Думаю, их контрибуторов, майнтейнеров и пользователей это не
 MS> волнует.  :)

Кстати: если контрибуторов, мейнтейнеров и пользователей бэкпортов и
правда не волнует, то зачем здесь это обсуждать?  Первноачальный вопрос
был такой: "нам закрыли компонент в багзилле, который мы abuse'или, и
теперь у нас нет возможности попросить переложить пакет в бранч!" И
аналогичный посыл от перекладывателей: "у нас закрыли incoming (хотя и
не закрывали), теперь мы не можем переложить пакет в бранч!".

Держись. Желающие перекладывать, но не осилившие git.alt, будут хотеть
бэкпортить. Возможно, бэкпорты от этого станут немножко живее. А может и
нет.

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Evgeny Sinelnikov]

26 февраля 2009 г. 19:16 пользователь Mikhail Gusarov
<dottedmag@altlinux.org> написал:
>
> Twas brillig at 19:10:53 26.02.2009 UTC+03 when sbolshakov@altlinux.ru did gyre and gimble:
>
>  SB> Непонятно только, почему на таковых исканиях-метаниях необходимо
>  SB> задействовать инфраструктуру проекта sisyphus -- ей определённо
>  SB> найдутся лучшие применения.
>
> Я вижу только один повод "за": желающие таких "backports" не умеют и не
> могут самостоятельно оповестить желающих пользоваться такими "backports"
> о том, что такие "backports" существуют.
>
> Мне малопонятно откуда взялась такая проблема (и аналогичная ей -
> неумение быть апстримом), но она существует.
>
> Впрочем, можно задействовать инфраструктуру минимально: wiki и planet. И
> тогда желающие бэкпортить смогут бэкпортить в совершенно любом удобном
> для них виде.
>

Дело не только в backport, как куче именных дедалов... Я уже вёл речь,
о том, что для _совместной работы_ бывает полезно иметь отдельный
временный репозиторий. Привлекать для этого сторонние ресурсы
интернета крайне не разумно... Я не думаю, что ALT Linux based сборки
интересны кому-нибудь вне ALT Linux Community, но они действительно
интересны внутри сообщества.

Я думаю, что иметь возможность сделать несколько дополнительных
репозиториев под текущие задачи (java, gcc, openssl, python2.6...)
гораздо более уместно, чем отправлять людей "браздить" в просторах
интернета в поисках ресурсов для решения проблем разработки. Вопрос в
том как их потом чистить...

Вариант же именных репозиториев мне не очень нравится... Я думаю, что
совместной работе это будет мешать. Мне нравится вариант использования
task'ов, как временных репозиториев... Но время их жизни, наверное,
может быть не велико. Зато это не сильно выходит за рамки текущей
архитектуры. Может быть git.alt стоит научить делать доп. репозитории
сборка в которые будет проходить на заданном наборе других
репозиториев, определяющих сборочную среду? Это и будут тогда те самые
дедалы...

Тут нужно найти компромисс между двумя разными задачами:
- Выложить свои сборку с минимальным объёмом ответственности...
Именные репозитории здесь удобны.
- Начать разламывание важной части не трогая основную ветку (Сизиф)...
Здесь удобны дедалусы под задачу.

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

Скажем так, я, и видимо не один, гораздо чаще выкладывал бы свои
сборки в неком именном или специальной дедалусе, если бы такая
возможность была... Но не в общую кучу, именуемую Dаedalus или
backport, а в отдельный репозиторий, который не столь опасно
подключать. Мне кажется, что в этом есть явная потребность у отдельных
участников ALT.

-- 
Sin (Sinelnikov Evgeny)

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Alexey Tourbin]

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

On Thu, Feb 26, 2009 at 10:46:03PM +0300, Evgeny Sinelnikov wrote:
> Тут нужно найти компромисс между двумя разными задачами:
> - Выложить свои сборку с минимальным объёмом ответственности...
> Именные репозитории здесь удобны.

Мне кажется, что такие сборки особо никому не нужны.  Вы поймите,
rpm пакеты не существуют сами по себе.  Они существуют и имеют смысл
только тогда, когда их удается состыковать со всем остальным, c master
репозитарием.  Но в момент такого согласования сам master репозитарий
меняется.  И тогда существует модель данных, которая отслеживает и
описывает такие согласования.  Непротиворечивое согласование будет
называться "транзакцией" и т.д.

> - Начать разламывание важной части не трогая основную ветку (Сизиф)...
> Здесь удобны дедалусы под задачу.

Рзаламывайте у себя в RPMS.hasher, это и будет дедалус.
Когда всё разломанное почитилось, тогда это будет заданием в Сизиф.

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

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

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Mikhail Gusarov]

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


Twas brillig at 23:02:20 26.02.2009 UTC+03 when at@altlinux.ru did gyre and gimble:

 AT> Рзаламывайте у себя в RPMS.hasher, это и будет дедалус.

Вопрос в том, как координировать такой разлом, если он затрагивает
многих мейнтейнеров одновременно.

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Alexey Tourbin]

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

On Fri, Feb 27, 2009 at 02:04:42AM +0600, Mikhail Gusarov wrote:
>  AT> Рзаламывайте у себя в RPMS.hasher, это и будет дедалус.
> 
> Вопрос в том, как координировать такой разлом, если он затрагивает
> многих мейнтейнеров одновременно.

Я писал про "задания и схемы совместной работы".
Сейчас реализовано две схемы.

1) NMU.  Если починка чужих пакетов, которые разломались, выглядит
тривильно, то можно осуществить её самому.  Тогда (при отсутствии
других нарушений) можно надеяться, что будет подтверждение NMU --
либо от мейнтейнера, либо от girar_root aka ldv.

2) Если починить чужие пакеты нетривиально (например, обновление на
новую версию), тогда лучше делать shared task.  Тогда мейнтейнер сам
соберёт новую версию (или, во всяком случае, он сам должен подписать
таг для новой сборки пакета) и добавит в shared task.

То есть в принципе схемы продуманы, хотя и не факт что они очень удобны.
Для тривиальных изменений -- NMU, для нетривиальных -- shared task.

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Mikhail Gusarov]

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


Twas brillig at 23:15:13 26.02.2009 UTC+03 when at@altlinux.ru did gyre and gimble:

 AT> для нетривиальных -- shared task.

Такой shared task и есть описываемый "дедальчик", если промежуточные
состояния оформить как apt-able репозиторий для тестирования.

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Evgeny Sinelnikov]

26 февраля 2009 г. 23:02 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> On Thu, Feb 26, 2009 at 10:46:03PM +0300, Evgeny Sinelnikov wrote:
>> Тут нужно найти компромисс между двумя разными задачами:
>> - Выложить свои сборку с минимальным объёмом ответственности...
>> Именные репозитории здесь удобны.
>
> Мне кажется, что такие сборки особо никому не нужны.  Вы поймите,

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

> rpm пакеты не существуют сами по себе.  Они существуют и имеют смысл
> только тогда, когда их удается состыковать со всем остальным, c master
> репозитарием.  Но в момент такого согласования сам master репозитарий
> меняется.  И тогда существует модель данных, которая отслеживает и
> описывает такие согласования.  Непротиворечивое согласование будет
> называться "транзакцией" и т.д.
>

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

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

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

>> - Начать разламывание важной части не трогая основную ветку (Сизиф)...
>> Здесь удобны дедалусы под задачу.
>
> Рзаламывайте у себя в RPMS.hasher, это и будет дедалус.
> Когда всё разломанное почитилось, тогда это будет заданием в Сизиф.
>

Если я работаю один, то я так и делаю, но у нас что нет пакетов с
зависимостями? Библиотеки, модули... Как я всё это буду тестировать
один в RPMS.hasher?

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

Это всё ясно... но не столь критично, когда речь идёт о совместном
тестировании. Стоит ли поддерживать кучу расплодившихся веток - это
вопрос конечно... Всё чего вы можете опасаться, как мне кажется - это
чьё-либо желание в некоторый момент переложить вместо пересобрать ;)


-- 
Sin (Sinelnikov Evgeny)

Re: [devel] backports und branches (was: ALT: Liberte, egalite, fraternite ou la Mort?)

[Led]

On Thursday, 26 February 2009 18:22:35 Michael Shigorin wrote:
> On Thu, Feb 26, 2009 at 06:57:47PM +0300, Alexey Tourbin wrote:
> > > >> c введением acl возникла нужда в полноценных backports.
> > >
> > > DVL> Объясните мне, что это такое?
> > > Это репозиторий в котором контроль качества минимален,
> > > собрать туда может каждый и без acl, и который по сути будет
> > > способом каждого опубликовать то что он хочет.
> > > Проще говоря это либо contrib если речь идет о
> > > централизованом репо, либо по репо каждому в people.
> > > Последний вариант мне особенно нравится.
> >
> > Консолидации работы минимум
>
> Это не так.
>
> > разницы с ftp/ rsync.altlinux.org::people минимум.
>
> Это тем более не так.
>
> PS: майнтейнер backports вовсе не прочь, чтоб его заменили
> скриптом, но также считает, что с введением:
>  * acl в бранчах
>  * требования по версиям относительно сизифа
> -- работа внешних по отношению ко всяким ООО людей может
> практически прекратиться.  Уж больно много сложностей.
>
> Про ACL мне лично непонятно совсем, про версии -- понятно
> в меру того, что у меня сизиф есть и используется, равно как
> и _множество_ бранчей на его основе (а не один конкретный).
>
> Я не возьмусь объяснять коллегам на Камчатке, что решив взяться
> за активную админ-поддержку пакета в бранче -- у них нет выбора,
> кроме как становиться разработчиками и вести его же в сизифе.
> Контактных майнтейнеров, которые способны к диалогу, у нас не
> сто процентов, к сожалению.
>
> On Thu, Feb 26, 2009 at 07:10:53PM +0300, Sergey Bolshakov wrote:
> > >>> c введением acl возникла нужда в полноценных backports.
> >
> > DVL> Объясните мне, что это такое?
> >
> > > Это репозиторий в котором контроль качества минимален,
> > > собрать туда может каждый и без acl, и который по сути будет
> > > способом каждого опубликовать то что он хочет.
>
> Не совсем так.
>
> Бэкпорты относятся к бранчам, как дедал -- к сизифу.
> (тем, кто не понимает, чем ценен дедал, просьба не влазить)
>
> > Непонятно только, почему на таковых исканиях-метаниях
> > необходимо задействовать инфраструктуру проекта sisyphus -- ей
> > определённо найдутся лучшие применения.
>
> Слушай, собственник -- эта инфраструктура не твоя личная.
> Прекрати выдавать своё маргинальное мнение по этому вопросу
> за разумное. :)
>
> 2 devel: я знаю ровно двоих активных сторонников ACL:
> sbolshakov@ и legion@.  Всё.  Активных противников знаю
> минимум столько же (slava@ и led@).

Ты ошибаешся: я как раз сторонник ACL (хоть и нестолько "активный"). Мне не 
нравится только их "одностороннее действие" (когда кто-то "застолбил" софтину 
и бросил) - ACL'и не пересматриваются и подвергаются ревизии то тех пор, пока 
на эти "брошенные" пакеты почему-то не обратит кто-то из 2-3-4 человек 
(сами-знаете-кто).

-- 
Led

Re: [devel] backports und branches

[Alexey Rusakov]

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

В Чтв, 26/02/2009 в 18:54 +0200, Michael Shigorin пишет:
> On Thu, Feb 26, 2009 at 07:42:52PM +0300, Sergey Bolshakov wrote:
> >  >> Непонятно только, почему на таковых исканиях-метаниях
> >  >> необходимо задействовать инфраструктуру проекта sisyphus --
> >  >> ей определённо найдутся лучшие применения.
> >  > Слушай, собственник -- эта инфраструктура не твоя личная.
> >  > Прекрати выдавать своё маргинальное мнение по этому вопросу
> >  > за разумное. :)
> > Ой, ну да, я забыл предварить строчкой 'по моему
> > (маргинальному) мнению', хотя, ээ, стой, разве я был замечен
> > в высказывании мнений, не подходящих под ?
> 
> Ниже.
> 
> >  > 2 devel: я знаю ровно двоих активных сторонников ACL:
> >  > sbolshakov@ и legion@.  Всё.  Активных противников знаю
> >  > минимум столько же (slava@ и led@).  Сам считаю, что ACL
> >  > нужны, но с другим дефолтом -- когда "маркировка территории"
> >  > является бременем желающего её "охранять", а не производится
> >  > автоматически.
> > Я сторонник персональной ответственности, acl -- способ.
> 
> Я уже натыкался на проблемы с тем, что ты (опытный человек)
> чего-то не учитывал, а вылазило это в самый неподходящий момент
> (например, на стенде в декабре 2007, когда мы с led@ срочно
> чинили pulseaudio, взаимодействовать по которому он с тех пор
> с тобой отказался, как и icesik@, которого тоже к тому пытался
> сподвигнуть).
> 
> И я время от времени готовлю списки пакетов, которыми никто не
> занимается и которые заблокированы по ACL.  Две редакции меня
> убедили в достаточной мере, что бессрочные автоматические
> персональные ACL -- это зло.
> 
> С legion@ и ldv@ это тоже обсуждалось, причём в итоге для меня
> ACL в бранчах стали полной неожиданностью: Terminal 4.0 я бы так
> попросту не смог выпустить, ну или требовать себе этакий suid.
> Который мне не нужен.
Почитав вашу живую дискуссию, позволю себе высказаться (не как член тим,
а как, э-э, функционер). Порядок работы, который использовался при
выпуске Terminal 4.0 или даже нашего недавнего Школьного сервера - хорош
лишь тогда, когда над одним бранчем нечаянно не сталкиваются лбами две
конторы, желающие выпустить каждая свой дистрибутив примерно в одно и то
же время. Если у этих дистрибутивов оказывается конфликт по фичам
каких-то пакетов - жди беды. Т.е. это в итоге окажется либо два пакета с
разными именами, каждый для своего дистра, либо потерянное время и нервы
на согласование усилий. Я понимаю, что до сей поры таких прецедентов не
было, но по моим ощущениям, мы уже недалеко от первого из них (я ни на
что не намекаю).

Отседа делаю вывод: если хочется оперативно допиливать дистрибутивы в
последние две недели, имеет смысл это делать в публичных, но при этом
отдельных от бранча местах. Соответственно, вопрос о "персональных
дедалах/backport'ах"  мне кажется актуальным. Если бы у git.alt появился
соратник в виде инфраструктуры для бинарных репозиториев... мне кажется,
это было бы не так уж плохо.

-- 
  Alexey "Ktirf" Rusakov
  Project Manager
  ALT Linux

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

Re: [devel] backports und branches

[Sergey Bolshakov]

>>>>> "Led" == Led  <ledest-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
[skipped]

 >> 2 devel: я знаю ровно двоих активных сторонников ACL:
 >> sbolshakov@ и legion@.  Всё.  Активных противников знаю
 >> минимум столько же (slava@ и led@).

 > Ты ошибаешся: я как раз сторонник ACL (хоть и нестолько "активный"). Мне не 
 > нравится только их "одностороннее действие" (когда кто-то "застолбил" софтину 
 > и бросил) - ACL'и не пересматриваются и подвергаются ревизии то тех пор, пока 
 > на эти "брошенные" пакеты почему-то не обратит кто-то из 2-3-4 человек 
 > (сами-знаете-кто).

Собственно, что мешает договориться о неких правилах смещения
майнтайнера, если он мышей не ловит ?
К примеру, баги с важностью критично и выше, висящие без
движения/починки эн дней приводят к _автоматическому_ nobody@
на пакет, то же лекарство для пакетов непересобирающихся.
Имеющийся в багзилле патч/ссылка на коммит -- обстоятельство
отягчающее.

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

-- 

Re: [devel] backports und branches

[Alexey Tourbin]

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

On Thu, Feb 26, 2009 at 11:57:55PM +0300, Alexey Rusakov wrote:
> Отседа делаю вывод: если хочется оперативно допиливать дистрибутивы в
> последние две недели, имеет смысл это делать в публичных, но при этом
> отдельных от бранча местах. Соответственно, вопрос о "персональных
> дедалах/backport'ах"  мне кажется актуальным. Если бы у git.alt появился

Почему публиковать исходники недостаточно, а хочется непременно
публиковать бинарную "насадку" не репозитарий?

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

Re: [devel] backports und branches

[Alexey Rusakov]

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

В Птн, 27/02/2009 в 00:28 +0300, Alexey Tourbin пишет:
> On Thu, Feb 26, 2009 at 11:57:55PM +0300, Alexey Rusakov wrote:
> > Отседа делаю вывод: если хочется оперативно допиливать дистрибутивы в
> > последние две недели, имеет смысл это делать в публичных, но при этом
> > отдельных от бранча местах. Соответственно, вопрос о "персональных
> > дедалах/backport'ах"  мне кажется актуальным. Если бы у git.alt появился
> 
> Почему публиковать исходники недостаточно, а хочется непременно
> публиковать бинарную "насадку" не репозитарий?
Потому что git-репозитории в дистрибутив положить, конечно, можно, но не
думаю, что даже бета-тестеры это поймут.

-- 
  Alexey "Ktirf" Rusakov
  Project Manager
  ALT Linux

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

Re: [devel] backports und branches

[Alexey Tourbin]

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

On Fri, Feb 27, 2009 at 12:33:39AM +0300, Alexey Rusakov wrote:
> В Птн, 27/02/2009 в 00:28 +0300, Alexey Tourbin пишет:
> > On Thu, Feb 26, 2009 at 11:57:55PM +0300, Alexey Rusakov wrote:
> > > Отседа делаю вывод: если хочется оперативно допиливать дистрибутивы в
> > > последние две недели, имеет смысл это делать в публичных, но при этом
> > > отдельных от бранча местах. Соответственно, вопрос о "персональных
> > > дедалах/backport'ах"  мне кажется актуальным. Если бы у git.alt появился
> > 
> > Почему публиковать исходники недостаточно, а хочется непременно
> > публиковать бинарную "насадку" не репозитарий?
> Потому что git-репозитории в дистрибутив положить, конечно, можно, но не
> думаю, что даже бета-тестеры это поймут.

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

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

Минимальнаую гарантию, которую даёт персональный дедал, -- это
sisyphus_check.  Это очень мало.  Гарантий согласования никаких нет.

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

Re: [devel] backports und branches

[Mikhail Gusarov]

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


Twas brillig at 00:45:38 27.02.2009 UTC+03 when at@altlinux.ru did gyre and gimble:

 AT> Минимальнаую гарантию, которую даёт персональный дедал, -- это
 AT> sisyphus_check.  Это очень мало.  Гарантий согласования никаких
 AT> нет.

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

-- 

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

Re: [devel] backports und branches

[Alexey Tourbin]

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

On Fri, Feb 27, 2009 at 03:46:59AM +0600, Mikhail Gusarov wrote:
>  AT> Минимальнаую гарантию, которую даёт персональный дедал, -- это
>  AT> sisyphus_check.  Это очень мало.  Гарантий согласования никаких
>  AT> нет.
> 
> Всё-таки до сих пор не понятно, почему персональный дедал не может быть
> не оверлеем, а полным репозиторием.

А как это сделать?  Хардлинками вроде сделать нельзя, потому что разные
файловые системы.  А копировать это сколько гигазов будет.  И кто это
будет скачивать, даже если и хардлинками.  Если мы не в хост-систему
ставим, то как скчивателю объяснить, что там хардлинки?

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

Re: [devel] backports und branches

[Mikhail Gusarov]

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


Twas brillig at 01:10:38 27.02.2009 UTC+03 when at@altlinux.ru did gyre and gimble:

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

 AT> А как это сделать?  Хардлинками вроде сделать нельзя, потому что
 AT> разные файловые системы.

Разные? Это плохо. Впрочем, не совсем плохо.

 AT> А копировать это сколько гигазов будет.

Достаточно одной копии сизифа для каждой файловой системы.

 AT> И кто это будет скачивать, даже если и хардлинками.

Скачивать не надо, достаточно apt направить.

-- 

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

Re: [devel] backports und branches

[Alexey Rusakov]

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

В Птн, 27/02/2009 в 00:45 +0300, Alexey Tourbin пишет:
> On Fri, Feb 27, 2009 at 12:33:39AM +0300, Alexey Rusakov wrote:
> > В Птн, 27/02/2009 в 00:28 +0300, Alexey Tourbin пишет:
> > > On Thu, Feb 26, 2009 at 11:57:55PM +0300, Alexey Rusakov wrote:
> > > > Отседа делаю вывод: если хочется оперативно допиливать дистрибутивы в
> > > > последние две недели, имеет смысл это делать в публичных, но при этом
> > > > отдельных от бранча местах. Соответственно, вопрос о "персональных
> > > > дедалах/backport'ах"  мне кажется актуальным. Если бы у git.alt появился
> > > 
> > > Почему публиковать исходники недостаточно, а хочется непременно
> > > публиковать бинарную "насадку" не репозитарий?
> > Потому что git-репозитории в дистрибутив положить, конечно, можно, но не
> > думаю, что даже бета-тестеры это поймут.
> 
> То есть у Вас на последних стадиях подготовки дистрибутива просто
> копируются пакеты из одного места в другое место.
> 
> Это не годится с точки зрения базовой технологии разработки репозитария.
> По идее все пакеты должны пройти через одну и ту же бюрократию/процедуру,
> тогда есть гарантия, что выполняются определнные требования.
> 
> Минимальнаую гарантию, которую даёт персональный дедал, -- это
> sisyphus_check.  Это очень мало.  Гарантий согласования никаких нет.
Пусть проходят, на здоровье. Но потом, когда уляжется пыль. Просто уже
не раз и не два на моих глазах при подготовке дистрибутива иной пакет за
день обновлялся по нескольку раз, потому что
сборка-тест-багрепорт-исправление-сборка.... И не всегда тестер и
собирающий сидят в одной комнате, и даже городе. Инфраструктуры для
такой деятельности сейчас толком нет, а юз-кейс встречается отнюдь не
только при подготовке дистрибутивов.

-- 
  Alexey "Ktirf" Rusakov
  Project Manager
  ALT Linux

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

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

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

On Thu, Feb 26, 2009 at 02:26:48PM +0300, Dmitry V. Levin wrote:

>> Единый.
DVL> Единого backports при живых ветках я себе не представляю.

IMHO backports отличается от ветки уровнем протестированности.

Есть, скажем, 4.0. Хороший такой дистрибутив. А что будет если я захочу на
нем, ну например, самый свежий KDE?

Или реальный пример -- я таки планирую собрать asterisk 1.6. Так вот
класть его в stable я не уверен что правильно. И dist-upgrade на ветке не
должен заменить 1.4 на 1.6. Однако ряд людей захочет сделать apt-get
install asterisk1.6.

Тому есть два пути:
1. backports
2. 
  people/mithraen/4.0/asterisk1.6
  people/mithraen/4.1/asterisk1.6
  people/mithraen/5.0/asterisk1.6

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

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

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

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

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

On Thu, Feb 26, 2009 at 05:33:14PM +0600, Mikhail Gusarov wrote:


MG> Кратая резолюция треда:
MG> 1. Для удобства разработки - сделать "карманы" в girar.
MG> 2. Если кому-то хочется делать бэкпорты - он придёт сюда и об это
MG>    скажет, и подскажет, чего ему не нравится в реализации "карманов"
MG> 3. Если никто не придёт - значит есть много пользователей, которым нужен
MG>    свежий софт, но собирать его некому, и эти пользователи остаются "с
MG>    носом".

+1

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

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

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

Re: [devel] задания и схемы совместной работы

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

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

On Thu, Feb 26, 2009 at 07:10:23PM +0300, Алексей Турбин wrote:

>> Об этом и речь.
>> Как это реально будет выглядеть?
>> Будет ли это похоже на pocket, о котором говорил Денис?
AT> Я не знаю, что такое pocket, это не было строго описано.

Описываю.

Pockets это некоторый репозиторий, который строится на базе среза сизифа на
определенный момент времени (момент создания pocket'а) и пакетов которые
были собраны в рамках этого task.

Его особенности:

- пригоден для работы apt-get (в отличии от task'а);
- в него после начала работы можно добавлять, удалять пакеты, и вообще
  вести себя с ним как с еще одним репозиторием на равных правах с двумя
  уже имеющимся в girar (создавать новые task'и, копировать пакеты, и
  т.д.);
- этот репозиторий, в отличии от "обычных" не гарантирует отсутствия
  unmet'ов, возможно какие-либо другие проверки тоже в нем будут
  отключены;
- в любой момент времени можно дать команду "rebase" -- это попытка
  сделать rebase на последнее состояние репозитория, из которого делался
  pocket;
- в любой момент можно дать команду "commit" -- в этом случае все
  изменения в этом pocket'е попытаются примениться как один единый task к
  Сизифу, в случае неудачи -- соответственно будет лог об ошибках и
  возможность доработать pocket для того чтобы его можно было безопасно
  заcommit'ить;

Логика выполнения commit:
- блокировать все пользовательские операции в этом pocket
- сделать rebase (речь не о git rebase, разумеется, а о том что в репо
  находится свежий сизиф + все измененные пакеты - все удаленные пакеты в
  этом pocket);
- повторно пересобрать все пакеты внутри этого pocket (для гарантии
  собираемости);
- выполнить _копирование_ пакетов в Сизиф;

Необходимость копирования объясняется именно возможностью выполнения
bootstrap'ов всяких. После цепочки изменений которая происходит внутри
pocket'а не гарантируется что хоть один пакет из pocket вообще возможно
собрать в исходном репозитории;

AT> В общем, есть как бы pockets, но с достаточно жесткими условиями
AT> по части кто за что отвечает.

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

Также task'и сейчас не являются полноценными доступными извне
репозиториями.

AT> Какие ещё схемы можно придумать, чтобы людям было проще договориться?

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

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

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

Re: [devel] backports und branches

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

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

On Fri, Feb 27, 2009 at 02:24:20AM +0300, Alexey Rusakov wrote:

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

Если бы такая инфраструктура была -- мне бы работу над дистрибутивом с
астериском это сильно облегчило бы.

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

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

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Led]

On Friday, 27 February 2009 06:31:49 REAL wrote:
> Mikhail Gusarov пишет:
> > А какие тут аргументы, кроме того, что "всё равно поставят"? Напомню,
> > что обновлялись до sisyphus исключительно из-за отвратительного
> > developer-oriented документирования, что же такое есть sisyphus, во всех
> > возможных местах. Это исправили, и обновляться до sisyphus пользователи
> > перестали.
>
> Я обновлялся как раз из-за developer-oriented сизифа. Мне в нём проще
> жить, чем на какой-либо из стабильных веток. Особенно помню "красоту",
> когда была убита возможность собрать на 4.0 пакет из сизифа, ибо lzma.

Можно было собрать. То, что вы не знали как, ещё не значит, что "была убита".

>
> Теперь же меня ни на дистрибутив, ни на бранч никакими пряниками не
> заманишь.

-- 
Led

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[REAL]

Mikhail Gusarov пишет:
> А какие тут аргументы, кроме того, что "всё равно поставят"? Напомню,
> что обновлялись до sisyphus исключительно из-за отвратительного
> developer-oriented документирования, что же такое есть sisyphus, во всех
> возможных местах. Это исправили, и обновляться до sisyphus пользователи
> перестали.

Я обновлялся как раз из-за developer-oriented сизифа. Мне в нём проще 
жить, чем на какой-либо из стабильных веток. Особенно помню "красоту", 
когда была убита возможность собрать на 4.0 пакет из сизифа, ибо lzma.

Теперь же меня ни на дистрибутив, ни на бранч никакими пряниками не 
заманишь.

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[REAL]

Mikhail Gusarov пишет:
> 1. Для удобства разработки - сделать "карманы" в girar.

А можно хотя бы в двух словах расписать, что подразумевается под 
"карманами"? Особенно интересует техническая, а не "философская" 
сторона вопроса.

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[REAL]

Kirill A. Shutemov пишет:
>> Низкий порог вхождения рождает красноглазое коммунити. (ц)
> Именно это мне больше всего не нравится в Ruby. :(

С Java, увы, ситуация не лучше.

Тут хороший пример - Lisp (но и тут не без урода в семье, достаточно 
вспомнить AutoCAD).

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[REAL]

Led пишет:
>> Я обновлялся как раз из-за developer-oriented сизифа. Мне в нём проще
>> жить, чем на какой-либо из стабильных веток. Особенно помню "красоту",
>> когда была убита возможность собрать на 4.0 пакет из сизифа, ибо lzma.
> Можно было собрать. То, что вы не знали как, ещё не значит, что "была убита".

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

Вообще, если мне нужен целый набор (и достаточно массивный) пакетов в 
актуальном состоянии, здесь сизифу альтернатив просто не существует. 
Это не значит, что я вдруг начну следить за самыми свежими версиями 
обслуживающего софта (скажем, тот же mpd или какой-нибудь 
iptables/sendmail), но вот rpm/gear/hasher/gcc/glibc/итп - оно просто 
нужно самое свежее, ибо иначе пропадает смысл пытаться что-либо 
полноценно и безглючно собирать для сизифа.

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[REAL]

Evgeny Sinelnikov пишет:
> Вариант же именных репозиториев мне не очень нравится... Я думаю, что
> совместной работе это будет мешать.

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


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

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

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[REAL]

Alexey Tourbin пишет:
> Рзаламывайте у себя в RPMS.hasher, это и будет дедалус.
> Когда всё разломанное почитилось, тогда это будет заданием в Сизиф.

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

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Evgeny Sinelnikov]

27 февраля 2009 г. 4:08 пользователь Денис Смирнов
<mithraen@altlinux.ru> написал:
> On Thu, Feb 26, 2009 at 02:26:48PM +0300, Dmitry V. Levin wrote:
>
>>> Единый.
> DVL> Единого backports при живых ветках я себе не представляю.
>
> IMHO backports отличается от ветки уровнем протестированности.
>

backports, как общая свалка, ломает многие из действительных
возможностей тестирования. если вы собираете asterisk1.6, а кто-то
туда бросил ещё


> Есть, скажем, 4.0. Хороший такой дистрибутив. А что будет если я захочу на
> нем, ну например, самый свежий KDE?
>
> Или реальный пример -- я таки планирую собрать asterisk 1.6. Так вот
> класть его в stable я не уверен что правильно. И dist-upgrade на ветке не
> должен заменить 1.4 на 1.6. Однако ряд людей захочет сделать apt-get
> install asterisk1.6.
>
> Тому есть два пути:
> 1. backports
> 2.
>  people/mithraen/4.0/asterisk1.6
>  people/mithraen/4.1/asterisk1.6
>  people/mithraen/5.0/asterisk1.6
>
> --
> С уважением, Денис
>
> http://freesource.info
> ----------------------------------------------------------------------------
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkmnPR0ACgkQPuR8c4jhFKITiACggv/JuBM3XwE6VH6z4KGM+ktJ
> hlYAoIYo66ketcb2BGH6u77Y83Ay8+wx
> =kBNK
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
>



-- 
Sin (Sinelnikov Evgeny)

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Alexey Tourbin]

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

On Fri, Feb 27, 2009 at 12:25:03PM +0700, REAL wrote:
> Alexey Tourbin пишет:
> >Рзаламывайте у себя в RPMS.hasher, это и будет 
> >дедалус.
> >Когда всё разломанное почитилось, тогда 
> >это будет заданием в Сизиф.
> 
> В этой ситуации дополнительно нужно 
> прикладывать совет автоматически 
> посылать восвояси любого, кто просит 
> портирование под бранч.

Прямо какое-то сочувствие детям Германии, я не знаю.
По полтиннику штука.

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Evgeny Sinelnikov]

27 февраля 2009 г. 4:08 пользователь Денис Смирнов
<mithraen@altlinux.ru> написал:
> On Thu, Feb 26, 2009 at 02:26:48PM +0300, Dmitry V. Levin wrote:
>
>>> Единый.
> DVL> Единого backports при живых ветках я себе не представляю.
>
> IMHO backports отличается от ветки уровнем протестированности.
>

backports, как общая свалка, ломает многие из действительных
возможностей тестирования. если вы собираете asterisk1.6, а кто-то
туда бросил ещё и gcc новый и ещё KDE4 в придачу, то работать с таким
доп. репозиторием становится невозможно...

> Есть, скажем, 4.0. Хороший такой дистрибутив. А что будет если я захочу на
> нем, ну например, самый свежий KDE?
>
> Или реальный пример -- я таки планирую собрать asterisk 1.6. Так вот
> класть его в stable я не уверен что правильно. И dist-upgrade на ветке не
> должен заменить 1.4 на 1.6. Однако ряд людей захочет сделать apt-get
> install asterisk1.6.
>
> Тому есть два пути:
> 1. backports
> 2.
>  people/mithraen/4.0/asterisk1.6
>  people/mithraen/4.1/asterisk1.6
>  people/mithraen/5.0/asterisk1.6
>

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


-- 
Sin (Sinelnikov Evgeny)

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Evgeny Sinelnikov]

27 февраля 2009 г. 9:08 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> On Fri, Feb 27, 2009 at 12:25:03PM +0700, REAL wrote:
>> Alexey Tourbin пишет:
>> >Рзаламывайте у себя в RPMS.hasher, это и будет
>> >дедалус.
>> >Когда всё разломанное почитилось, тогда
>> >это будет заданием в Сизиф.
>>
>> В этой ситуации дополнительно нужно
>> прикладывать совет автоматически
>> посылать восвояси любого, кто просит
>> портирование под бранч.
>
> Прямо какое-то сочувствие детям Германии, я не знаю.
> По полтиннику штука.
>

Причём тут сочувствие? Все недоделки, aka backports, которые в бранч
не ложатся требуют тестирования. Качество же тестирования в
RPMS.hasher не сравнимо ниже, тестирования в рамках сообщества. С
другой стороны, тестирование в рамках не контролируемой сборочной
среды (Daedalus или backports) - дело весьма сомнительное. Тем не
менее тестировать на всём сообществе (Sisyphus и бранчи) - дело не
всегда оправданное...


-- 
Sin (Sinelnikov Evgeny)

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Aleksey Avdeev]

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

Evgeny Sinelnikov пишет:
> 27 февраля 2009 г. 4:08 пользователь Денис Смирнов
> <mithraen@altlinux.ru> написал:
...
>>
>> Тому есть два пути:
>> 1. backports
>> 2.
>>  people/mithraen/4.0/asterisk1.6
>>  people/mithraen/4.1/asterisk1.6
>>  people/mithraen/5.0/asterisk1.6
>>
> 
> Я думаю, что оба эти пути не удобны.... Первый тем, что в свалке
> возникают конфликты - сборочная среда не контролируется рамками некой
> задачи. Второй тем, что слишком маргинален и не позволяет вести
> совместную работу...

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

> Нужен третий вариант и как его сделать лучше -
> pocket'ами или иными средствами - вопрос уже технический.

-- 

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



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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Mikhail Gusarov]

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


Twas brillig at 13:58:48 27.02.2009 UTC+07 when root@mmedia2.kemsu.ru did gyre and gimble:

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

IMHO, это FUD. За время, потраченное на написание в эту тему писем,
можно было бы десяток пакетов переложить из Сизифа в бранчи.

Для этого всего-то и нужно - прочитать git.alt quickstart на wiki, всё
там разжёвано в двух страницах текста.

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[REAL]

Evgeny Sinelnikov пишет:
> Причём тут сочувствие? Все недоделки, aka backports, которые в бранч
> не ложатся требуют тестирования.

Тут ещё момент есть, уже из жизни. Было желание увидеть пакет gsl в 
бранче то ли 4.0, то ли 4.1, точно не помню. Поскольку майнтайнеру это 
неинтересно, я бы мог и сам попробовать, но, честно скажу, что 
разбираться с нуля в чужом пакете, чтобы его провести по бранчам, 
начиная с 5.0 включительно... не считаю себя настолько хорошо 
разбирающемся в данной конкретной теме, да и времени столько 
свободного нет, увы (к тому же через ту же цепочку пришлось бы 
протаскивать и свой пакет). Выход нашёл простой, но очень уж с 
червоточинкой: собрать свой пакет _без_ поддержки gsl. Налицо регресс 
уже в самом сизифе, ибо в нём-то как раз gsl есть, но в данном случае 
не используется. Зато не пришлось и свой пакет никуда портировать, ибо 
static library.

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[REAL]

Mikhail Gusarov пишет:
> IMHO, это FUD. За время, потраченное на написание в эту тему писем,
> можно было бы десяток пакетов переложить из Сизифа в бранчи.

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

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Stanislav Ievlev]

Это всё надуманные страхи. Каждый раз когда появляется новая технология - в
community@ начинается истерика у отдельных товарищей.

Вместо успокоения что git.alt - дело добровольное, лучше сказать что
git.alt - это просто. Презентацию например какую-нибудь сделать.

backports совершенно не нужны при наличии нормальных бранчей.

Не стоит идти на поводу у толпы и откатываться в прошлое. Те кто психуют
как правило на join и так не идут, а нормальные разработчики с git.alt
справятся без проблем.


On Thu, Feb 26, 2009 at 12:02:18PM +0200, Igor Vlasenko wrote:
> Уважаемые коллеги,
> кто в танке, прошу обратить внимание на
> бурную дискуссию в community по git.alt.
> 
> Грубо говоря, надо 
> 1) пояснить, что переезд на git.alt -- дело добровольное.
> 2) не повышать порог вхождения
> Не затруднять работу тех, кто не осилил git.alt,
> но умеет src.rpm, иначе вся наша тим потеряет большую
> часть потенциальных участников.
> 3) не хватает возможности при желании откатиться -
> переехать с git.alt на srpm.
> 4) Надо возродить backports.
> 
> Нам нужны:
> и ясли -- backports
> и школа -- src.rpms
> и университет -- git.alt
> и все это вместе.
> 
> Чтобы не было, что тим стала как ракета.
> Некоторая меньшая часть сбросила предварительную 
> ступень и улетела в космос для поиска в вакууме 
> сферического коня, а остальные сгорели :(
> 
> Liberte, Egalite, Fraternite, ou Сизифу будет la Mort
> 
> 
> <QUOTE>--------------------------------------
> Motsyo Gennadi aka Drool пишет:
> > Timur Batyrshin пишет:
> >>> заниматься интимом с git.alt.
> >>
> >> Дык веди разработку сразу в нем. Тем более, что это удобнее.
> > 
> >     Мне неудобно. Плюсов для себя, кроме одного - совместная разработка
> > (да и то мне это сомнительно), я не увидел. Геморроя стало больше.
> > Телодвижений - тоже.
> 
> Раз пошла такая [пьянка] дискуссия - расскажите мне текущую политику
> относительно git и старого incoming. Ибо за рассылками внимательно не
> слежу и не в курсе ситуации.
> 
> Вот я типа майнтейнер, поддерживаю целых пять пакетов. Дела с git не
> имел и, честно говоря, иметь не хочу. Коллективной разработки над моими
> пакетами нет и не предвидится. Тратить день на то, чтобы разбираться с
> git у меня нет ни времени, ни желания, поскольку это будет сопряжено с
> чтением уймы документации и письмами в рассылку (смотри ниже).
> ------------------------------------------</QUOTE>
> 
> -- 
> 
> Dr. Igor Vlasenko
> --------------------
> Topology Department
> Institute of Math
> Kiev, Ukraine
> 
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Evgeny Sinelnikov]

27 февраля 2009 г. 11:30 пользователь Stanislav Ievlev
<inger@altlinux.org> написал:
> Это всё надуманные страхи. Каждый раз когда появляется новая технология - в
> community@ начинается истерика у отдельных товарищей.
>
> Вместо успокоения что git.alt - дело добровольное, лучше сказать что
> git.alt - это просто. Презентацию например какую-нибудь сделать.
>

А может честно признаться, что src.rpm -> git.alt - это эволюционный
процесс, что src.rpm изжил себя как формат для обмена исходниками
между разработчиками, что происходит слияние процесса разработки и
сборки приложений в дистрибутивах и что git.alt - это один из самых
развитых подходов?

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

> backports совершенно не нужны при наличии нормальных бранчей.
>

Нет, я продолжаю вести речь о том, что проблема в промежуточном
тестировании... И backports для этого слишком неоднозначная сборочная
среда... Нужны групповые репозитории... Будут они временными или
постоянными, назовём их боксами или покетами - не столь важно... Было
бы удобно с ними работать через git.alt.

А сами backports, в текущем их представлении - это частный случай
таких репозиториев. ИМХО, действительно, малополезный.

> Не стоит идти на поводу у толпы и откатываться в прошлое. Те кто психуют
> как правило на join и так не идут, а нормальные разработчики с git.alt
> справятся без проблем.
>
>
> On Thu, Feb 26, 2009 at 12:02:18PM +0200, Igor Vlasenko wrote:
>> Уважаемые коллеги,
>> кто в танке, прошу обратить внимание на
>> бурную дискуссию в community по git.alt.
>>
>> Грубо говоря, надо
>> 1) пояснить, что переезд на git.alt -- дело добровольное.
>> 2) не повышать порог вхождения
>> Не затруднять работу тех, кто не осилил git.alt,
>> но умеет src.rpm, иначе вся наша тим потеряет большую
>> часть потенциальных участников.
>> 3) не хватает возможности при желании откатиться -
>> переехать с git.alt на srpm.
>> 4) Надо возродить backports.
>>
>> Нам нужны:
>> и ясли -- backports
>> и школа -- src.rpms
>> и университет -- git.alt
>> и все это вместе.
>>
>> Чтобы не было, что тим стала как ракета.
>> Некоторая меньшая часть сбросила предварительную
>> ступень и улетела в космос для поиска в вакууме
>> сферического коня, а остальные сгорели :(
>>
>> Liberte, Egalite, Fraternite, ou Сизифу будет la Mort
>>
>>
>> <QUOTE>--------------------------------------
>> Motsyo Gennadi aka Drool пишет:
>> > Timur Batyrshin пишет:
>> >>> заниматься интимом с git.alt.
>> >>
>> >> Дык веди разработку сразу в нем. Тем более, что это удобнее.
>> >
>> >     Мне неудобно. Плюсов для себя, кроме одного - совместная разработка
>> > (да и то мне это сомнительно), я не увидел. Геморроя стало больше.
>> > Телодвижений - тоже.
>>
>> Раз пошла такая [пьянка] дискуссия - расскажите мне текущую политику
>> относительно git и старого incoming. Ибо за рассылками внимательно не
>> слежу и не в курсе ситуации.
>>
>> Вот я типа майнтейнер, поддерживаю целых пять пакетов. Дела с git не
>> имел и, честно говоря, иметь не хочу. Коллективной разработки над моими
>> пакетами нет и не предвидится. Тратить день на то, чтобы разбираться с
>> git у меня нет ни времени, ни желания, поскольку это будет сопряжено с
>> чтением уймы документации и письмами в рассылку (смотри ниже).
>> ------------------------------------------</QUOTE>
>>

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


-- 
Sin (Sinelnikov Evgeny)

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Igor Vlasenko]

On Fri, Feb 27, 2009 at 11:30:02AM +0300, Stanislav Ievlev wrote:
> backports совершенно не нужны при наличии нормальных бранчей.

Гайки чересчур закручены с acl.
Много людей не поддерживают бранчи,
т. е. там в acl прописаны не те люди.
Нужны какие-то механизмы, 
например вроде групп товарищей, которые
право имеют раздавать acl на бранчи.

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Evgeny Sinelnikov]

27 февраля 2009 г. 20:44 пользователь Igor Vlasenko
<vlasenko@imath.kiev.ua> написал:
> On Fri, Feb 27, 2009 at 11:30:02AM +0300, Stanislav Ievlev wrote:
>> backports совершенно не нужны при наличии нормальных бранчей.
>
> Гайки чересчур закручены с acl.
> Много людей не поддерживают бранчи,
> т. е. там в acl прописаны не те люди.
> Нужны какие-то механизмы,
> например вроде групп товарищей, которые
> право имеют раздавать acl на бранчи.
>

Я так понимаю, что сейчас, для 5.0, всё просто... собираете, делаете
новый task и есть о чём вести разговор... Для старых бранчей всё не
совсем понятно...

-- 
Sin (Sinelnikov Evgeny)

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Mikhail Gusarov]

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


Twas brillig at 21:09:26 27.02.2009 UTC+03 when sin@altlinux.ru did gyre and gimble:

 ES> Я так понимаю, что сейчас, для 5.0, всё просто... собираете,
 ES> делаете новый task и есть о чём вести разговор... Для старых
 ES> бранчей всё не совсем понятно...

$ ssh git.alt task new --help
usage: girar-task new [<binary_repository_name>]
Valid repositories are: sisyphus 5.0 4.1 4.0

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Evgeny Sinelnikov]

27 февраля 2009 г. 21:10 пользователь Mikhail Gusarov
<dottedmag@altlinux.org> написал:
>
> Twas brillig at 21:09:26 27.02.2009 UTC+03 when sin@altlinux.ru did gyre and gimble:
>
>  ES> Я так понимаю, что сейчас, для 5.0, всё просто... собираете,
>  ES> делаете новый task и есть о чём вести разговор... Для старых
>  ES> бранчей всё не совсем понятно...
>
> $ ssh git.alt task new --help
> usage: girar-task new [<binary_repository_name>]
> Valid repositories are: sisyphus 5.0 4.1 4.0
>

Ну, так это же замечательно... ;)


-- 
Sin (Sinelnikov Evgeny)

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Motsyo Gennadi aka Drool]

Igor Vlasenko пишет:
> On Fri, Feb 27, 2009 at 11:30:02AM +0300, Stanislav Ievlev wrote:
>> backports совершенно не нужны при наличии нормальных бранчей.
> 
> Гайки чересчур закручены с acl.
> Много людей не поддерживают бранчи,
> т. е. там в acl прописаны не те люди.
> Нужны какие-то механизмы, 
> например вроде групп товарищей, которые
> право имеют раздавать acl на бранчи.

	Может глупость сморожу, но лучше скромно спросить, чем гордо не знать. 
Можно ли сделать разные ACL в сизиф и бранчах? Это было бы удобно - не 
хочет/не может мантейнер собирать пакет в бранчи, так пусть даст ACL 
мне, к примеру. И у него голова не болит, и я доволен.

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Mikhail Gusarov]

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


Twas brillig at 20:42:45 27.02.2009 UTC+02 when motsyo@gmail.com did gyre and gimble:

 MGaD> Может глупость сморожу, но лучше скромно спросить, чем гордо не
 MGaD> знать. Можно ли сделать разные ACL в сизиф и бранчах?

Можно, но только ручками: ssh git.alt 5.0 mypackage add @anybody, или
как-то так.

Глобального рубильника "все мои пакеты - на nobody в бранче" нет.

-- 

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

Re: [devel] backports und branches

[Michael Shigorin]

On Fri, Feb 27, 2009 at 12:23:06AM +0300, Sergey Bolshakov wrote:
>  >> 2 devel: я знаю ровно двоих активных сторонников ACL:
>  >> sbolshakov@ и legion@.  Всё.  Активных противников знаю
>  >> минимум столько же (slava@ и led@).
>  > Ты ошибаешся: я как раз сторонник ACL (хоть и нестолько
>  > "активный"). Мне не нравится только их "одностороннее
>  > действие"

Так сторонник или не нравится?  _В текущем_ виде мне ACL
кажутся вредными.  То, что они в ряде случаев полезны или
критичны -- знаю.

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

>  > (когда кто-то "застолбил" софтину и бросил) - ACL'и не
>  > пересматриваются и подвергаются ревизии то тех пор, пока на
>  > эти "брошенные" пакеты почему-то не обратит кто-то из 2-3-4
>  > человек (сами-знаете-кто).
> Собственно, что мешает договориться о неких правилах смещения
> майнтайнера, если он мышей не ловит ?
> К примеру, баги с важностью критично и выше, висящие без
> движения/починки эн дней приводят к _автоматическому_ nobody@
> на пакет, то же лекарство для пакетов непересобирающихся.
> Имеющийся в багзилле патч/ссылка на коммит -- обстоятельство
> отягчающее.

Или так.

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

Так вот отож.

Предлагаю заменить возлагание дополнительной работы на комиссию
(в которую не пойду ни разу) возлаганием дополнительной работы
на желающих столбить.  Возможно, как-то автоматизировав
настройками git.alt (флажок "я столбю").

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

Re: [devel] backports und branches

[Igor Vlasenko]

On Fri, Feb 27, 2009 at 09:21:41PM +0200, Michael Shigorin wrote:
> Предлагаю заменить возлагание дополнительной работы на комиссию
> (в которую не пойду ни разу) возлаганием дополнительной работы
> на желающих столбить.  Возможно, как-то автоматизировав
> настройками git.alt (флажок "я столбю").
+100

-- 

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

Re: [devel] backports und branches

[Aleksey Novodvorsky]

27 февраля 2009 г. 22:21 пользователь Michael Shigorin
<mike@osdn.org.ua> написал:
> On Fri, Feb 27, 2009 at 12:23:06AM +0300, Sergey Bolshakov wrote:
>>  >> 2 devel: я знаю ровно двоих активных сторонников ACL:
>>  >> sbolshakov@ и legion@.  Всё.  Активных противников знаю
>>  >> минимум столько же (slava@ и led@).
>>  > Ты ошибаешся: я как раз сторонник ACL (хоть и нестолько
>>  > "активный"). Мне не нравится только их "одностороннее
>>  > действие"
>
> Так сторонник или не нравится?  _В текущем_ виде мне ACL
> кажутся вредными.  То, что они в ряде случаев полезны или
> критичны -- знаю.
>
> Я ещё сужу по тому, насколько часто спрашивал кого-либо
> по "случайным" наступаниям или спрашивали меня (крайне редко);
> в сравнение с тем, когда обламываешься починить что-то умеренно
> нужное просто потому, что разводить тягомотину себе дороже,
> эта частота просто не идёт.
>
>>  > (когда кто-то "застолбил" софтину и бросил) - ACL'и не
>>  > пересматриваются и подвергаются ревизии то тех пор, пока на
>>  > эти "брошенные" пакеты почему-то не обратит кто-то из 2-3-4
>>  > человек (сами-знаете-кто).
>> Собственно, что мешает договориться о неких правилах смещения
>> майнтайнера, если он мышей не ловит ?
>> К примеру, баги с важностью критично и выше, висящие без
>> движения/починки эн дней приводят к _автоматическому_ nobody@
>> на пакет, то же лекарство для пакетов непересобирающихся.
>> Имеющийся в багзилле патч/ссылка на коммит -- обстоятельство
>> отягчающее.
>
> Или так.
>
>> Понятно, что следует явно оговорить, по каким признакам баг
>> может считаться критичным, да завести некую конфликтную
>> коммисию.
>
> Так вот отож.
>
> Предлагаю заменить возлагание дополнительной работы на комиссию
> (в которую не пойду ни разу) возлаганием дополнительной работы
> на желающих столбить.  Возможно, как-то автоматизировав
> настройками git.alt (флажок "я столбю").

Звучит неплохо. Можно это изложить в виде маленького проекта полиси?

Rgrds, Алексей

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Motsyo Gennadi aka Drool]

Mikhail Gusarov пишет:
>  MGaD> Может глупость сморожу, но лучше скромно спросить, чем гордо не
>  MGaD> знать. Можно ли сделать разные ACL в сизиф и бранчах?
> 
> Можно, но только ручками: ssh git.alt 5.0 mypackage add @anybody, или
> как-то так.

	Ну, этого уже достаточно для разговора с мантейнером.

> Глобального рубильника "все мои пакеты - на nobody в бранче" нет.

	Главное что возможно.

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Michael Shigorin]

On Thu, Feb 26, 2009 at 10:36:44PM +0300, Alexey Tourbin wrote:
> Бекпорты это вообще глупость какая-то.  Если сбекпортить все
> пакеты, то получится Sisyphus, только намного хуже.

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

Гругря, работает у тебя что-то на glibc 2.5 и каши не просит,
но один сервис хочется иметь распоследней версии.  Делать из-за
такого dist-upgrade не пойми куда обычно не хочется, особенно
если за то, что система работает -- ты зряплату получаешь,
а вот за эксперименты с потерей этого свойства -- никак нет.

Пойми, сизиф сам по себе нафиг не нужен.  Как и линукс.
И вообще весь этот хайтек.  Насколько он полезен "на выходе"
-- настолько и нужен.

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Aleksey Avdeev]

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

Grigory Batalov пишет:
...
> 
> Я считаю, каждый разработчик должен освоить хотя бы одну VCS (CVS, Subversion).
> Для линуксоидов - git хороший выбор.

   +1: Сильно помогает при разработке чего-либо не тривиального (когда 
на средине работы понимаешь, что некоторые вещи надо было делать по 
другому)...

-- 

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



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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Aleksey Novodvorsky]

28 февраля 2009 г. 20:58 пользователь Michael Shigorin
<mike@osdn.org.ua> написал:
> On Thu, Feb 26, 2009 at 10:36:44PM +0300, Alexey Tourbin wrote:
>> Бекпорты это вообще глупость какая-то.  Если сбекпортить все
>> пакеты, то получится Sisyphus, только намного хуже.
>
> Только причина этого -- не в глупости бэкпортов, а в глупости
> изначальной посылки.
>
> Гругря, работает у тебя что-то на glibc 2.5 и каши не просит,
> но один сервис хочется иметь распоследней версии.


Есть два варианта.
1. Найдется менйтейнер, желающий помочь.
2.  Найдется мейнтейнер, желающий заработать.

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


Делать из-за
> такого dist-upgrade не пойми куда обычно не хочется, особенно
> если за то, что система работает -- ты зряплату получаешь,

Вот именно. Если ты получаешь зарплату, то можешь и заплатить за то,
что тебе нужно для твоей работы, если самому влом разбираться.
Я не предлагаю ни   в коем случае коммерциализировать все отношения.
Чем больше некоммерческих отношений, -- тем лучше. Но и _требовать_
сделать что-то за красивые глаза не вполне  корректно. Я здесь не имю
в виду фирму Альт Линукс, у нас здесь не одна фирма представлена и не
один из членов тим готов был бы немного заработать.

А инфраструктуру мы сделаем и для 1, и для 2.


> а вот за эксперименты с потерей этого свойства -- никак нет.
>
> Пойми, сизиф сам по себе нафиг не нужен.  Как и линукс.
> И вообще весь этот хайтек.  Насколько он полезен "на выходе"
> -- настолько и нужен.

Это крайняя точка зрения, но спорить сейчас не хочу. В значительной
степени -- верно, но квантор общности и тут не стал бы вешать. Вопрос
в  трактовке слова "полезен".

Rgrds, Алексей

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Michael Shigorin]

On Sat, Feb 28, 2009 at 09:14:30PM +0300, Aleksey Avdeev wrote:
> Grigory Batalov пишет:
> >Я считаю, каждый разработчик должен освоить хотя бы одну VCS
> >(CVS, Subversion).  Для линуксоидов - git хороший выбор.
> +1: Сильно помогает при разработке чего-либо не тривиального
> (когда на средине работы понимаешь, что некоторые вещи надо
> было делать по другому)...

Мужики, ещё раз: если майнтейнер участвует в апстриме --
замечательно.  Но если ему кровь из носу надо, чтоб результат
работал -- поверьте, _его_ коллегам такие пакеты будут ценней.

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

Это во многом вопрос целеполагания -- проекта и его участников.

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Michael Shigorin]

On Sat, Feb 28, 2009 at 09:15:57PM +0300, Aleksey Novodvorsky wrote:
> > Гругря, работает у тебя что-то на glibc 2.5 и каши не просит,
> > но один сервис хочется иметь распоследней версии.
> Есть два варианта.
> 1. Найдется менйтейнер, желающий помочь.
> 2. Найдется мейнтейнер, желающий заработать.

Я не о том :)  А о том, зачем нужно бэкпортирование.
Разумеется, вслепую всё и вся -- нет ни смысла, ни возможности.
Поскольку soname changes prohibited.

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

Это другой вопрос, но -- тоже да, глядя на мозилье царство.

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

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

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

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

Ага.

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

Ну я намеренно сгустил краски -- тот же фофан является
существенным фактором, но это развлечение за счёт других.
Т.е. _рассчитывать_ на чей-то фан не следует.

> Вопрос в  трактовке слова "полезен".

Разумеется.

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Mikhail Gusarov]

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


Twas brillig at 20:28:43 28.02.2009 UTC+02 when mike@osdn.org.ua did gyre and gimble:

 MS> Поскольку soname changes prohibited.

Решение этого, кстати, давно уже предложено. Кто-то реализует, кто-то -
нет.

-- 

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Alexey Tourbin]

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

On Sat, Feb 28, 2009 at 07:58:17PM +0200, Michael Shigorin wrote:
> On Thu, Feb 26, 2009 at 10:36:44PM +0300, Alexey Tourbin wrote:
> > Бекпорты это вообще глупость какая-то.  Если сбекпортить все
> > пакеты, то получится Sisyphus, только намного хуже.
> 
> Только причина этого -- не в глупости бэкпортов, а в глупости
> изначальной посылки.
> 
> Гругря, работает у тебя что-то на glibc 2.5 и каши не просит,
> но один сервис хочется иметь распоследней версии.  Делать из-за
> такого dist-upgrade не пойми куда обычно не хочется, особенно
> если за то, что система работает -- ты зряплату получаешь,
> а вот за эксперименты с потерей этого свойства -- никак нет.

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

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

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

Короче, бывает целостный репозитарий, в котором пакеты "утрясаются",
и это всё описывается и фиксируется, как они там утрясяются, и какие
проблемы при этом возникают.

И бывает "анти-репозитарий", когда просто сваливают в один каталог все
пересобранные файлы с расширением *.rpm.  И говорят, что это что-то значит.
Называется бекпортс.

Посмотрим с другой стороны: пусть нужна очень стабильная система.
Очень стабильная система -- это когда по исходным условиям желательно
ничего не менять.  Есть два типа систем, в которых по исходным условиям
желательно ничего не менять:
1) сертифицированные системы;
2) системы с severe uptime requirements и downtime loss.

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

Если система допускает обновления из backports, то уже слишком
строгие требования к ней не предъявляются.

> Пойми, сизиф сам по себе нафиг не нужен.  Как и линукс.

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

А в бекпортах вообще никаких гарантий нет.
А в сизифе есть, и в бранчах тоже есть.

> И вообще весь этот хайтек.  Насколько он полезен "на выходе"
> -- настолько и нужен.

Проблема спроса интересная, но спрос это отдельно от базовых технологий.

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Led]

On Saturday, 28 February 2009 20:28:43 Michael Shigorin wrote:
> On Sat, Feb 28, 2009 at 09:15:57PM +0300, Aleksey Novodvorsky wrote:
> > > Гругря, работает у тебя что-то на glibc 2.5 и каши не просит,
> > > но один сервис хочется иметь распоследней версии.
> >
> > Есть два варианта.
> > 1. Найдется менйтейнер, желающий помочь.
> > 2. Найдется мейнтейнер, желающий заработать.
>
> Я не о том :)  А о том, зачем нужно бэкпортирование.
> Разумеется, вслепую всё и вся -- нет ни смысла, ни возможности.
> Поскольку soname changes prohibited.
>
> > Вообще, тема небесплатной помощи, на мой взгляд, должна
> > обсуждаться открыто, особенно в нынешние не очень благополучные
> > времена.
>
> Это другой вопрос, но -- тоже да, глядя на мозилье царство.
>
> > > Делать из-за такого dist-upgrade не пойми куда обычно не
> > > хочется, особенно если за то, что система работает -- ты
> > > зряплату получаешь,
> >
> > Вот именно. Если ты получаешь зарплату, то можешь и заплатить
> > за то, что тебе нужно для твоей работы, если самому влом
> > разбираться.
>
> Алексей, по умолчанию мои примеры основываются на себе в качестве
> кролика.  Я действительно обычно могу или справиться сам, или
> оплатить (или иначе компенсировать) расходы времени на помощь.
>
> Но это никак не меняет желательности иметь возможность точечных
> обновлений "хороших" в плане предсказуемости стабильности пакетов
> на стабильной же платформе.  Впрочем, кому рассказываю. :)

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

-- 
Led

[devel] смысл (was: ALT: Liberte, egalite, fraternite ou la Mort?)

[Michael Shigorin]

On Sat, Feb 28, 2009 at 09:32:17PM +0300, Alexey Tourbin wrote:
> > Гругря, работает у тебя что-то на glibc 2.5 и каши не просит,
> > но один сервис хочется иметь распоследней версии.
> Дело в том, что изолированные обновления возможны далеко не
> всегда.  Чтобы собрать прикладной пакет новой версии, для этого
> достаточно часто требуются библиотеки новых версий.

Лёш, ну разумеется, не всегда!

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

И ничего, на практике софт не настолько плох, как обычно кажется.

> И бывает "анти-репозитарий", когда просто сваливают в один
> каталог все пересобранные файлы с расширением *.rpm.  И
> говорят, что это что-то значит.  Называется бекпортс.

Примерно так по факту.  Но это проблема не концепции,
а реализации, и всё равно она не хуже, чем остающиеся
по localhost'ам исходные и бинарные пакеты.

backports же возникли на фоне кучи частных репозиториев,
когда ссылки под search.altlinux.ru уже переставали помещаться.

> Посмотрим с другой стороны: пусть нужна очень стабильная
> система.  Очень стабильная система -- это когда по исходным
> условиям желательно ничего не менять.  Есть два типа систем, в
> которых по исходным условиям желательно ничего не менять:
> 1) сертифицированные системы;
> 2) системы с severe uptime requirements и downtime loss.
> Тогда зачем такие системы обновлять и вообще что-то в них
> менять, тем более на уровне backports, я не понимаю.

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

> Если система допускает обновления из backports, то уже слишком
> строгие требования к ней не предъявляются.

Конечно.  Разве что к админу.

> > Пойми, сизиф сам по себе нафиг не нужен.  Как и линукс.
> Сизиф не настолько плох, чтобы из него обновиться и всё сломалось.
> По крайней мере, я прилагаю к этому некоторые усилия.

Тебе-то спасибо, но за все апстримы не ответишь.  Да и за всех
пламенных врагов проприетарщины вон. :)

> А в бекпортах вообще никаких гарантий нет.
> А в сизифе есть, и в бранчах тоже есть.

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

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

Разумеется.  Если помнишь мои публичные и offlist-высказывания
насчёт R&D, то сам понимаешь -- знаю.

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

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Aleksey Novodvorsky]

28 февраля 2009 г. 21:47 пользователь Led <ledest@gmail.com> написал:
> On Saturday, 28 February 2009 20:28:43 Michael Shigorin wrote:
>> On Sat, Feb 28, 2009 at 09:15:57PM +0300, Aleksey Novodvorsky wrote:
>> > > Гругря, работает у тебя что-то на glibc 2.5 и каши не просит,
>> > > но один сервис хочется иметь распоследней версии.
>> >
>> > Есть два варианта.
>> > 1. Найдется менйтейнер, желающий помочь.
>> > 2. Найдется мейнтейнер, желающий заработать.
>>
>> Я не о том :)  А о том, зачем нужно бэкпортирование.
>> Разумеется, вслепую всё и вся -- нет ни смысла, ни возможности.
>> Поскольку soname changes prohibited.
>>
>> > Вообще, тема небесплатной помощи, на мой взгляд, должна
>> > обсуждаться открыто, особенно в нынешние не очень благополучные
>> > времена.
>>
>> Это другой вопрос, но -- тоже да, глядя на мозилье царство.
>>
>> > > Делать из-за такого dist-upgrade не пойми куда обычно не
>> > > хочется, особенно если за то, что система работает -- ты
>> > > зряплату получаешь,
>> >
>> > Вот именно. Если ты получаешь зарплату, то можешь и заплатить
>> > за то, что тебе нужно для твоей работы, если самому влом
>> > разбираться.
>>
>> Алексей, по умолчанию мои примеры основываются на себе в качестве
>> кролика.  Я действительно обычно могу или справиться сам, или
>> оплатить (или иначе компенсировать) расходы времени на помощь.
>>
>> Но это никак не меняет желательности иметь возможность точечных
>> обновлений "хороших" в плане предсказуемости стабильности пакетов
>> на стабильной же платформе.  Впрочем, кому рассказываю. :)
>
> Возможно ты в чём-то прав (может, в основном прав)... Но мой небогатый опыт
> говорит мне о том, что любой т.н. бэкпорт пакета (или группы пакетов) - это
> всегода сильно кастомная задача (по целям, способам реализации и преследуемым
> фичам и целям). Я согласен, что необходимость в подобных бэкпортах
> периодически возникает. Но если свалить все бэкпорты (с разными целями,
> подходами и т.п.) в общую песочницу.инфрастуктуру, то ничего хорошего кроме
> помойки ИМХО не получится. Но, возможно, моё мнение и ошибочно:)

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

Rgrds, Алексей

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Alexey Tourbin]

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

On Sat, Feb 28, 2009 at 09:15:57PM +0300, Aleksey Novodvorsky wrote:
> 28 февраля 2009 г. 20:58 пользователь Michael Shigorin
> <mike@osdn.org.ua> написал:
> > On Thu, Feb 26, 2009 at 10:36:44PM +0300, Alexey Tourbin wrote:
> >> Бекпорты это вообще глупость какая-то.  Если сбекпортить все
> >> пакеты, то получится Sisyphus, только намного хуже.
> >
> > Только причина этого -- не в глупости бэкпортов, а в глупости
> > изначальной посылки.
> >
> > Гругря, работает у тебя что-то на glibc 2.5 и каши не просит,
> > но один сервис хочется иметь распоследней версии.
> 
> Есть два варианта.
> 1. Найдется менйтейнер, желающий помочь.
> 2.  Найдется мейнтейнер, желающий заработать.

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

> Для обоих вариантов нужна инфраструктура.

А что такое инфраструктура?  Вся инфраструктура уже развёрнута, и с
точки зрения поддержки целостности пакетов это наилучшая из имеющихся
где-либо инфраструктур.

Люди хотят какую-то другую инфраструктуру, где их не отфутболивают.

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Michael Shigorin]

On Sat, Feb 28, 2009 at 10:09:40PM +0300, Alexey Tourbin wrote:
> > Есть два варианта.
> > 1. Найдется менйтейнер, желающий помочь.
> > 2.  Найдется мейнтейнер, желающий заработать.
> Наиболее вероятен вариант, что не найдётся и не найдётся.
> Потому что желание довольно странное.  Для очень стабильных
> систем, в которых всё работает и в которых желательно ничего не
> трогать, для таких систем нет причины специально заниматься
> ламерской сборкой пакетов.  А у систем с другими требованиями
> будет другой расклад.

Лёш, для Master 2.4 я поддерживал apache-1.3 с исправлениями
по безопасности.  А в backports/2.4 были (и тоже оперативно
поддерживались!) сборки с дополнительной функциональностью.
И я использовал и те, и те в разных местах.

Зачем обязательно ламерской?

> > Для обоих вариантов нужна инфраструктура.
> А что такое инфраструктура?  Вся инфраструктура уже развёрнута,
> и с точки зрения поддержки целостности пакетов это наилучшая из
> имеющихся где-либо инфраструктур.

Но пока не наилучший из возможных workflow, что и видим по треду.

> Люди хотят какую-то другую инфраструктуру, где их не отфутболивают.

Вот и поразмысли над разницей между lkml и *bsd commit access
на досуге.  Смысл брать git и делать из него коммиттерище
позорное -- от меня устойчиво ускользает.

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Aleksey Novodvorsky]

28 февраля 2009 г. 22:09 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> On Sat, Feb 28, 2009 at 09:15:57PM +0300, Aleksey Novodvorsky wrote:
>> 28 февраля 2009 г. 20:58 пользователь Michael Shigorin
>> <mike@osdn.org.ua> написал:
>> > On Thu, Feb 26, 2009 at 10:36:44PM +0300, Alexey Tourbin wrote:
>> >> Бекпорты это вообще глупость какая-то.  Если сбекпортить все
>> >> пакеты, то получится Sisyphus, только намного хуже.
>> >
>> > Только причина этого -- не в глупости бэкпортов, а в глупости
>> > изначальной посылки.
>> >
>> > Гругря, работает у тебя что-то на glibc 2.5 и каши не просит,
>> > но один сервис хочется иметь распоследней версии.
>>
>> Есть два варианта.
>> 1. Найдется менйтейнер, желающий помочь.
>> 2.  Найдется мейнтейнер, желающий заработать.
>
> Наиболее вероятен вариант, что не найдётся и не найдётся.  Потому что
> желание довольно странное.  Для очень стабильных систем, в которых всё
> работает и в которых желательно ничего не трогать, для таких систем нет
> причины специально заниматься ламерской сборкой пакетов.  А у систем с
> другими требованиями будет другой расклад.
>
>> Для обоих вариантов нужна инфраструктура.
>
> А что такое инфраструктура?  Вся инфраструктура уже развёрнута, и с
> точки зрения поддержки целостности пакетов это наилучшая из имеющихся
> где-либо инфраструктур.
>
> Люди хотят какую-то другую инфраструктуру, где их не отфутболивают.

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

Rgrds, Алексей

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Alexey Tourbin]

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

On Sat, Feb 28, 2009 at 09:13:41PM +0200, Michael Shigorin wrote:
> On Sat, Feb 28, 2009 at 10:09:40PM +0300, Alexey Tourbin wrote:
> > > Есть два варианта.
> > > 1. Найдется менйтейнер, желающий помочь.
> > > 2.  Найдется мейнтейнер, желающий заработать.
> > Наиболее вероятен вариант, что не найдётся и не найдётся.
> > Потому что желание довольно странное.  Для очень стабильных
> > систем, в которых всё работает и в которых желательно ничего не
> > трогать, для таких систем нет причины специально заниматься
> > ламерской сборкой пакетов.  А у систем с другими требованиями
> > будет другой расклад.
> 
> Лёш, для Master 2.4 я поддерживал apache-1.3 с исправлениями
> по безопасности.  А в backports/2.4 были (и тоже оперативно
> поддерживались!) сборки с дополнительной функциональностью.
> И я использовал и те, и те в разных местах.

Это торгуемо, если кто-то хочет поддерживать в старых бранчах обновления
лушче основного мейнтейнера в сизифе.  Вообще, long-time commitment
должен цениться (но, возможно, не с первого раза).

> Зачем обязательно ламерской?

Ну, например, я вспомнил, как ты обновил firefox в бранче более
оперативно, чем legion в сизифе.  На что legion посоветовал тебе
не бежать впереди паровоза.
http://lists.altlinux.org/pipermail/devel/2008-September/160791.html
Если бы мне пришлось оценивать по шкале ламерства усилия твои и усилия
легиона, то результат, скорее всего, был бы не в твою пользу.

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

Есть требования по обновляемости пакетов из старых бранчей на новые
бранчи; ldv на эту тему выскзался, а sbolshakov робко и притом как бы
немного нескромно подпел ему "браво".

Короче, есть технологические ограничения на workflow; они связаны
с гарантиями, которые дают базовые технологии.  Самая неприятная штука
из этой серии сейчас -- это новый ACL для бранчей; но есть и другие
штуки (e.g. требование по обновляемости на новые бранчи).

> > Люди хотят какую-то другую инфраструктуру, где их не отфутболивают.
> 
> Вот и поразмысли над разницей между lkml и *bsd commit access
> на досуге.  Смысл брать git и делать из него коммиттерище
> позорное -- от меня устойчиво ускользает.

Это немного другое, хотя конечно тоже имеет отношение.

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

Re: [devel] gear docs

[Aleksey Avdeev]

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

Eugene Ostapets пишет:
> 2009/2/26 Mikhail Gusarov <dottedmag altlinux.org>:
>> Twas brillig at 14:05:41 26.02.2009 UTC+02 when eostapets gmail.com did gyre and gimble:
...
>>
>>  EO> Требуется gear-rules(1) с обязательным переводом на русский. :)
>>
>> А это зачем?
> Для снижения порога, когда ты читаешь описание неизвестной технологии
> на малознакомом языке - очень тяжело понять какие моменты КЛЮЧЕВЫЕ, а
> какие вода для связи различных аспектов использования. Русский
> gear-rules(1) поможет понять что за технология и облегчит переход к
> чтению англоязычного gear-rules(5)

   +1: После прочтения документации на русском (даже устаревшей!!!) 
понять англоязычную на порядки проще.

-- 

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



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

Re: [devel] ACL in branches

[Dmitry V. Levin]

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

On Thu, Feb 26, 2009 at 06:54:25PM +0200, Michael Shigorin wrote:
[...]
> И я время от времени готовлю списки пакетов, которыми никто не
> занимается и которые заблокированы по ACL.  Две редакции меня
> убедили в достаточной мере, что бессрочные автоматические
> персональные ACL -- это зло.
> 
> С legion@ и ldv@ это тоже обсуждалось, причём в итоге для меня
> ACL в бранчах стали полной неожиданностью: Terminal 4.0 я бы так
> попросту не смог выпустить, ну или требовать себе этакий suid.
[...]
> Вот я бы сейчас пакеты led@ поправил в M50 и мож уже собирал
> потихоньку Terminal 5.0, а так всё руки не доходят его подёргать.
> Ему же этот M50 нафиг не упал, как понимаю.

А если ещё немного подумать?

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

Как сейчас происходит обработка пакетов, поступающих в бранч?
Поступающие пакеты проходят сборку с проверками на ACL, анметы двух типов,
корректность релиза, и пр.  Если все проверки прошли успешно, собранные
пакеты автоматически попадают в бранч, который автоматически публикуется.

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

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

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


-- 
ldv

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

Re: [devel] ACL in branches

[Alexey Rusakov]

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

В Вск, 01/03/2009 в 00:15 +0300, Dmitry V. Levin пишет:
> On Thu, Feb 26, 2009 at 06:54:25PM +0200, Michael Shigorin wrote:
> [...]
> > И я время от времени готовлю списки пакетов, которыми никто не
> > занимается и которые заблокированы по ACL.  Две редакции меня
> > убедили в достаточной мере, что бессрочные автоматические
> > персональные ACL -- это зло.
> > 
> > С legion@ и ldv@ это тоже обсуждалось, причём в итоге для меня
> > ACL в бранчах стали полной неожиданностью: Terminal 4.0 я бы так
> > попросту не смог выпустить, ну или требовать себе этакий suid.
> [...]
> > Вот я бы сейчас пакеты led@ поправил в M50 и мож уже собирал
> > потихоньку Terminal 5.0, а так всё руки не доходят его подёргать.
> > Ему же этот M50 нафиг не упал, как понимаю.
> 
> А если ещё немного подумать?
> 
> Как раньше выглядела обработка пакетов, поступавших в бранч?
> Пакеты поступали в инкаминг, проходили сборку без проверки ACL и
> складировались.  Примерно раз в неделю приходил мантейнер этого бранч,
> смотрел, что там насобиралось, и на глазок прикидывал, что из этого
> можно переложить в бранч.  Некоторые пакеты иногда после перекладывания
> ломали бранч, и их приходилось откатывать.  После этого обновлённый
> бранч публиковался.
> 
> Как сейчас происходит обработка пакетов, поступающих в бранч?
> Поступающие пакеты проходят сборку с проверками на ACL, анметы двух типов,
> корректность релиза, и пр.  Если все проверки прошли успешно, собранные
> пакеты автоматически попадают в бранч, который автоматически публикуется.
> 
> Таким образом, та ответственность, которая раньше лежала на мантейнере
> бранча, теперь разделена на 2 части: дополнительные проверки в скриптах
> обработки пакетов, и доверие мантейнерам, которые уже собирали этот пакет
> (проверка ACL пакетов).  В результате такого разделения ответственности
> публикация бранча превратилась из еженедельной в ежечасную.
Это всё хорошо, но есть одно "но". Не хочу никого обижать, но уровень
самосознания мейнтейнеров бранча существенно выше оного мейнтейнеров
некоторых пакетов. Проще говоря, теперь стало проще сделать доступным в
бранче пусть собирающийся, но нефункциональный пакет. Я очень хочу
верить, что у нас мейнтейнеры в большинстве своём люди ответственные, но
к сожалению, реальность не всегда эту веру оправдывает.

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

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

Re: [devel] ACL in branches

[Dmitry V. Levin]

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

On Sun, Mar 01, 2009 at 12:20:50AM +0300, Alexey Rusakov wrote:
> Это всё хорошо, но есть одно "но". Не хочу никого обижать, но уровень
> самосознания мейнтейнеров бранча существенно выше оного мейнтейнеров
> некоторых пакетов. Проще говоря, теперь стало проще сделать доступным в
> бранче пусть собирающийся, но нефункциональный пакет. Я очень хочу
> верить, что у нас мейнтейнеры в большинстве своём люди ответственные, но
> к сожалению, реальность не всегда эту веру оправдывает.

Другими словами, ты против автопубликации бранчей в её нынешнем виде?


-- 
ldv

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

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

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

On Sat, Feb 28, 2009 at 09:15:57PM +0300, Aleksey Novodvorsky wrote:

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

Вообще говоря инфраструктура нужна для обоих вариантов вне зависимости от
темы 'backports'.

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

Даже мои робкие попытки объявлять тут тендер на опакечивание -- тоже не
помогли (история закончилась тем что мне сказали "да" а потом я несколько
месяцев не получал результат -- он мне нужен был до конкретной даты чтобы
сдать заказчику, к счастью заказчику было пофиг на rpm и он получил машину
с ПО установленным из тарбола).

Такая инфраструктура должна содержать как минимум некоторые гарантии -- в
первую очередь исполнителю, что его не "кинут" (даже по независящим от
кидающего причинам, что в нынешние времена очень актуально), а также
некоторые возможности арбитража.

Как максимум -- возможность юридическим лицам платить официально через эту
систему исполнителям.

>> Делать из-за такого dist-upgrade не пойми куда обычно не хочется,
>> особенно если за то, что система работает -- ты зряплату получаешь,
AN> Вот именно. Если ты получаешь зарплату, то можешь и заплатить за то,
AN> что тебе нужно для твоей работы, если самому влом разбираться.

Это работает на практике обычно если 1 фичу хочет несколько человек.
Когда я работал _админом_ хоть зарплату я и получал, но заплатить за фикс
баги мог разве что единицы долларов. Если же есть возможность за фичу
предложить деньги нескольким людям, то результирующая сумма может быть
достаточно интересна чтобы мантейнер поработал :)

AN> Я не предлагаю ни   в коем случае коммерциализировать все отношения.
AN> Чем больше некоммерческих отношений, -- тем лучше. Но и _требовать_
AN> сделать что-то за красивые глаза не вполне  корректно. Я здесь не имю
AN> в виду фирму Альт Линукс, у нас здесь не одна фирма представлена и не
AN> один из членов тим готов был бы немного заработать.

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

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

А вот это -- индивидуально :)

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

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

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

Re: [devel] ACL in branches

[Alexey Rusakov]

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

В Вск, 01/03/2009 в 00:47 +0300, Dmitry V. Levin пишет:
> On Sun, Mar 01, 2009 at 12:20:50AM +0300, Alexey Rusakov wrote:
> > Это всё хорошо, но есть одно "но". Не хочу никого обижать, но уровень
> > самосознания мейнтейнеров бранча существенно выше оного мейнтейнеров
> > некоторых пакетов. Проще говоря, теперь стало проще сделать доступным в
> > бранче пусть собирающийся, но нефункциональный пакет. Я очень хочу
> > верить, что у нас мейнтейнеры в большинстве своём люди ответственные, но
> > к сожалению, реальность не всегда эту веру оправдывает.
> 
> Другими словами, ты против автопубликации бранчей в её нынешнем виде?
Она мне нравится, но мне не совсем спокойно за состояние бранчей. Просто
не совсем понятно, чем они на данный момент отличаются от Сизифа, чтоб
их стабильность была выше, чем Сизифа.

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

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

Re: [devel] ACL in branches

[Хихин Руслан]

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

Здравствуйте Alexey Rusakov
  В сообщении от 1 марта 2009 Alexey Rusakov написал(a):
> В Вск, 01/03/2009 в 00:47 +0300, Dmitry V. Levin пишет:
> > On Sun, Mar 01, 2009 at 12:20:50AM +0300, Alexey Rusakov 
wrote:
> > > Это всё хорошо, но есть одно "но". Не хочу никого обижать,
> > > но уровень самосознания мейнтейнеров бранча существенно
> > > выше оного мейнтейнеров некоторых пакетов. Проще говоря,
> > > теперь стало проще сделать доступным в бранче пусть
> > > собирающийся, но нефункциональный пакет. Я очень хочу
> > > верить, что у нас мейнтейнеры в большинстве своём люди
> > > ответственные, но к сожалению, реальность не всегда эту
> > > веру оправдывает.
> >
> > Другими словами, ты против автопубликации бранчей в её
> > нынешнем виде?
>
> Она мне нравится, но мне не совсем спокойно за состояние
> бранчей. Просто не совсем понятно, чем они на данный момент
> отличаются от Сизифа, чтоб их стабильность была выше, чем
> Сизифа.
Я немного пропустил, но у мантейнера должен быть "ключик" 
обновлять конкретные бренчи (от Сизифа до Бренч 4.0). Если 
мантейнер пересобрал пакет для Сизифа - это не зачит, что его-же 
надо автоматом пересобирать во всех бренчах. Теоретически это 
может быть невозможно или вредно (вариант - не работоспособно).


-- 
С  уважением Хихин Руслан

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] ACL in branches

[Alexey Rusakov]

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

В Вск, 01/03/2009 в 14:01 +0300, Хихин Руслан пишет:
> Здравствуйте Alexey Rusakov
>   В сообщении от 1 марта 2009 Alexey Rusakov написал(a):
> > В Вск, 01/03/2009 в 00:47 +0300, Dmitry V. Levin пишет:
> > > On Sun, Mar 01, 2009 at 12:20:50AM +0300, Alexey Rusakov 
> wrote:
> > > > Это всё хорошо, но есть одно "но". Не хочу никого обижать,
> > > > но уровень самосознания мейнтейнеров бранча существенно
> > > > выше оного мейнтейнеров некоторых пакетов. Проще говоря,
> > > > теперь стало проще сделать доступным в бранче пусть
> > > > собирающийся, но нефункциональный пакет. Я очень хочу
> > > > верить, что у нас мейнтейнеры в большинстве своём люди
> > > > ответственные, но к сожалению, реальность не всегда эту
> > > > веру оправдывает.
> > >
> > > Другими словами, ты против автопубликации бранчей в её
> > > нынешнем виде?
> >
> > Она мне нравится, но мне не совсем спокойно за состояние
> > бранчей. Просто не совсем понятно, чем они на данный момент
> > отличаются от Сизифа, чтоб их стабильность была выше, чем
> > Сизифа.
> Я немного пропустил, но у мантейнера должен быть "ключик" 
> обновлять конкретные бренчи (от Сизифа до Бренч 4.0). Если 
> мантейнер пересобрал пакет для Сизифа - это не зачит, что его-же 
> надо автоматом пересобирать во всех бренчах. Теоретически это 
> может быть невозможно или вредно (вариант - не работоспособно).
В каком смысле "ключик"? :) В каждый бранч пакет сейчас нужно явным
образом отдавать на сборку (кроме 5.0, но это дело времени). Но по
умолчанию это разрешено тем же людям, которые отправляют пакеты в Сизиф.
У меня есть ощущение, что человеческий фактор в этом плане может сыграть
злую шутку.

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

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Michael Shigorin]

On Sat, Feb 28, 2009 at 10:40:07PM +0300, Alexey Tourbin wrote:
> > Зачем обязательно ламерской?
> Ну, например, я вспомнил, как ты обновил firefox в бранче более
> оперативно, чем legion в сизифе.  На что legion посоветовал
> тебе не бежать впереди паровоза.

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

> http://lists.altlinux.org/pipermail/devel/2008-September/160791.html
> Если бы мне пришлось оценивать по шкале ламерства усилия твои и
> усилия легиона, то результат, скорее всего, был бы не в твою
> пользу.

Ну вообще-то я и не пытаюсь тут сравниваться. :)
Только оценивать скорей по шкале чайничества поэтому.

> > > Люди хотят какую-то другую инфраструктуру, где их не отфутболивают.
> > Вот и поразмысли над разницей между lkml и *bsd commit access
> > на досуге.  Смысл брать git и делать из него коммиттерище
> > позорное -- от меня устойчиво ускользает.
> Это немного другое, хотя конечно тоже имеет отношение.

Это к отношению к людям.  Технологии -- следствие.

"It also involves attitude.  But it also involves workflow.  And tools."
(c) http://www.opennet.ru/openforum/vsluhforumID3/42153.html#38

PS: прости, если чем обидел.

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

Re: [devel] ACL in branches

[Alexey Tourbin]

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

On Sun, Mar 01, 2009 at 05:24:31AM +0300, Alexey Rusakov wrote:
> В Вск, 01/03/2009 в 00:47 +0300, Dmitry V. Levin пишет:
> > Другими словами, ты против автопубликации бранчей в её нынешнем виде?
> Она мне нравится, но мне не совсем спокойно за состояние бранчей. Просто
> не совсем понятно, чем они на данный момент отличаются от Сизифа, чтоб
> их стабильность была выше, чем Сизифа.

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

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

Re: [devel] ACL in branches

[Хихин Руслан]

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

Здравствуйте Alexey Tourbin
  В сообщении от 2 марта 2009 Alexey Tourbin написал(a):
> On Sun, Mar 01, 2009 at 05:24:31AM +0300, Alexey Rusakov wrote:
> > В Вск, 01/03/2009 в 00:47 +0300, Dmitry V. Levin пишет:
> > > Другими словами, ты против автопубликации бранчей в её
> > > нынешнем виде?
> >
> > Она мне нравится, но мне не совсем спокойно за состояние
> > бранчей. Просто не совсем понятно, чем они на данный момент
> > отличаются от Сизифа, чтоб их стабильность была выше, чем
> > Сизифа.
>
> Неспокойно за состояние бранчей, поскольку не понятно, почему
> тогда бранчи должны быть стабильнее Сизифа.  Так-так-так.  А
> кто сказал, что бранчи должны быть стабильнее Сизифа?  Алексей
> Новодворский или кто?
Зачем нужен бренч ? 
Если он нужен, что-бы из него собирать дистрибутив (5.0), то он 
должен быть стабильнее Сизифа. Если он нужен как официальный 
источник обновления, то то-же. Если он нужен как вариант 
бекпорта, только непротиворечивый по зависимостям и т.п. - то 
ему не требутся ставильность выше Сизифа. 
В результате на ровном месте получаем два вида бренчей - более 
стабильные чем Сизиф (дистрибутиво-строительные) и равные Сизифу 
(бекпорты). Интересно ... :)


-- 
С  уважением Хихин Руслан

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] ACL in branches

[Alexey Tourbin]

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

On Mon, Mar 02, 2009 at 10:36:38PM +0300, Хихин Руслан wrote:
> > On Sun, Mar 01, 2009 at 05:24:31AM +0300, Alexey Rusakov wrote:
> > > Она мне нравится, но мне не совсем спокойно за состояние
> > > бранчей. Просто не совсем понятно, чем они на данный момент
> > > отличаются от Сизифа, чтоб их стабильность была выше, чем
> > > Сизифа.
> >
> > Неспокойно за состояние бранчей, поскольку не понятно, почему
> > тогда бранчи должны быть стабильнее Сизифа.  Так-так-так.  А
> > кто сказал, что бранчи должны быть стабильнее Сизифа?  Алексей
> > Новодворский или кто?
> Зачем нужен бренч ? 
> Если он нужен, что-бы из него собирать дистрибутив (5.0), то он 
> должен быть стабильнее Сизифа.

Нет причины, почему бранч должен быть стабильнее Сизифа.

Мы умеем проверять всякие довольно каверзные вещи.  Например, мы умеем
проверять устанавливаемость пакетов (в минимальный чрут).  Для всех
брачей без исключения можно реализовать проверку, встают новые пакеты
в минимальный чрут или нет.  Я сегодня такую проверку реализовал.  Она
ещё на заработала как следует, но завтра заработает.

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

> Если он нужен как официальный 
> источник обновления, то то-же. Если он нужен как вариант 
> бекпорта, только непротиворечивый по зависимостям и т.п. - то 
> ему не требутся ставильность выше Сизифа. 
> В результате на ровном месте получаем два вида бренчей - более 
> стабильные чем Сизиф (дистрибутиво-строительные) и равные Сизифу 
> (бекпорты). Интересно ... :)

Нет причины, почему бранч должен быть стабильнее Сизифа.

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

Re: [devel] ACL in branches

[Хихин Руслан]

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

Здравствуйте Alexey Tourbin
  В сообщении от 2 марта 2009 Alexey Tourbin написал(a):
> Единственная причина, почему бранч может быть стабильнее
> сизифа, -- это только потому, что бранч тестируют вручную.
>  Причем, реально. Установили паеты.  Запустили, пощелкали,
> посмотрели.  Подумали. Вроде работает.  Ну обезьяны там у них
> сидят.  В хорошем смысле слова.

Я про цели - а вы про методы их достижения. :)

-- 
С  уважением Хихин Руслан

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] ACL in branches

[Dmitry V. Levin]

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

On Mon, Mar 02, 2009 at 10:20:43PM +0300, Alexey Tourbin wrote:
> On Sun, Mar 01, 2009 at 05:24:31AM +0300, Alexey Rusakov wrote:
> > В Вск, 01/03/2009 в 00:47 +0300, Dmitry V. Levin пишет:
> > > Другими словами, ты против автопубликации бранчей в её нынешнем виде?
> > Она мне нравится, но мне не совсем спокойно за состояние бранчей. Просто
> > не совсем понятно, чем они на данный момент отличаются от Сизифа, чтоб
> > их стабильность была выше, чем Сизифа.
> 
> Неспокойно за состояние бранчей, поскольку не понятно, почему тогда
> бранчи должны быть стабильнее Сизифа.  Так-так-так.  А кто сказал, что
> бранчи должны быть стабильнее Сизифа?

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


-- 
ldv

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

Re: [devel] ALT: Liberte, egalite, fraternite ou la Mort?

[Alexey Tourbin]

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

On Thu, Feb 26, 2009 at 02:34:49PM +0300, Grigory Batalov wrote:
> On Thu, 26 Feb 2009 12:47:53 +0200
> Motsyo Gennadi aka Drool wrote:
> > 	Мне не нравится, лишние телодвижения. Но даже я со своим вечным нытьем 
> > понимаю что политику партии не изменить, теперь будет git и только так. 
> > Этот механизм осваивать придется, если я хочу что-то дальше заливать.
> 
> Ещё имейте в виду, что осваивая новые технологии вы повышаете свою капитализацию
> на рынке труда =)

Но самое главное, что переход на gear может увеличить размер полового члена.
Например, когда мейнтейнер собирал src.rpm пакеты то у него член был 10 см.
А когда он будет собирать из gear то уже на следующий день член будет 11 см!
По-моему, неплохая прибавка.

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

Re: [devel] ACL in branches

[Alexey Tourbin]

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

On Tue, Mar 03, 2009 at 12:44:51AM +0300, Dmitry V. Levin wrote:
> On Mon, Mar 02, 2009 at 10:20:43PM +0300, Alexey Tourbin wrote:
> > On Sun, Mar 01, 2009 at 05:24:31AM +0300, Alexey Rusakov wrote:
> > > В Вск, 01/03/2009 в 00:47 +0300, Dmitry V. Levin пишет:
> > > > Другими словами, ты против автопубликации бранчей в её нынешнем виде?
> > > Она мне нравится, но мне не совсем спокойно за состояние бранчей. Просто
> > > не совсем понятно, чем они на данный момент отличаются от Сизифа, чтоб
> > > их стабильность была выше, чем Сизифа.
> > 
> > Неспокойно за состояние бранчей, поскольку не понятно, почему тогда
> > бранчи должны быть стабильнее Сизифа.  Так-так-так.  А кто сказал, что
> > бранчи должны быть стабильнее Сизифа?
> 
> Бранчи -- это предметы, а предметы ничего не должны.  Мы можем сделать их
> стабильнее, если не будем отправлять туда экспериментальный софт.

Ну да.

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

Заработала проверка на устанавливаемость пакетов!

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

Re: [devel] [JT] ALT: Liberte, egalite, fraternite ou la Mort?

[Anton Farygin]

Alexey Tourbin пишет:
> On Thu, Feb 26, 2009 at 02:34:49PM +0300, Grigory Batalov wrote:
>> On Thu, 26 Feb 2009 12:47:53 +0200
>> Motsyo Gennadi aka Drool wrote:
>>> 	Мне не нравится, лишние телодвижения. Но даже я со своим вечным нытьем 
>>> понимаю что политику партии не изменить, теперь будет git и только так. 
>>> Этот механизм осваивать придется, если я хочу что-то дальше заливать.
>> Ещё имейте в виду, что осваивая новые технологии вы повышаете свою капитализацию
>> на рынке труда =)
> 
> Но самое главное, что переход на gear может увеличить размер полового члена.
> Например, когда мейнтейнер собирал src.rpm пакеты то у него член был 10 см.
> А когда он будет собирать из gear то уже на следующий день член будет 11 см!
> По-моему, неплохая прибавка.

Особенно забавно будет, если мантейнер - девушка. ;)

Re: [devel] ACL in branches

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

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

On Tue, Mar 03, 2009 at 08:00:33AM +0300, Алексей Турбин wrote:
AT> Просто разводили демагогию что бранчи это намного стабильнее сизифа
AT> потому что там неизвестно почему но с умным видом.  А теперь почва
AT> для демагогии стала уменьшаться как шагреневая кожа.
AT> Заработала проверка на устанавливаемость пакетов!

При нынешней технологии разработки -- бранчи не стабильнее Сизифа, они
просто более протухшие :)

Это плохо. Для выпуска дистрибутивов нужна стабильность. Под стабильностью
я подразумевая хотя бы:

- предсказуемые и заранее документированные изменения (то бишь когда
  сначала все узнают о том что что-то изменится серьезное, а потом оно
  изменится, это шпилька в адрес нашего инсталлятора);
- ручная протестированность;

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

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

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

Re: [devel] [JT] ALT: Liberte, egalite, fraternite ou la Mort?

[Grigory Batalov]

On Tue, 03 Mar 2009 09:20:48 +0300
Anton Farygin wrote:

> >>> 	Мне не нравится, лишние телодвижения. Но даже я со своим вечным нытьем 
> >>> понимаю что политику партии не изменить, теперь будет git и только так. 
> >>> Этот механизм осваивать придется, если я хочу что-то дальше заливать.
> >> Ещё имейте в виду, что осваивая новые технологии вы повышаете свою капитализацию
> >> на рынке труда =)
> > 
> > Но самое главное, что переход на gear может увеличить размер полового члена.
> > Например, когда мейнтейнер собирал src.rpm пакеты то у него член был 10 см.
> > А когда он будет собирать из gear то уже на следующий день член будет 11 см!
> > По-моему, неплохая прибавка.
> 
> Особенно забавно будет, если мантейнер - девушка. ;)

У неё увеличится грудь! =)

Re: [devel] [OT] ALT: Liberte, egalite, fraternite ou la Mort?

[Alexey Rusakov]

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

В Втр, 03/03/2009 в 11:21 +0300, Grigory Batalov пишет:
> On Tue, 03 Mar 2009 09:20:48 +0300
> Anton Farygin wrote:
> 
> > >>> 	Мне не нравится, лишние телодвижения. Но даже я со своим вечным нытьем 
> > >>> понимаю что политику партии не изменить, теперь будет git и только так. 
> > >>> Этот механизм осваивать придется, если я хочу что-то дальше заливать.
> > >> Ещё имейте в виду, что осваивая новые технологии вы повышаете свою капитализацию
> > >> на рынке труда =)
> > > 
> > > Но самое главное, что переход на gear может увеличить размер полового члена.
> > > Например, когда мейнтейнер собирал src.rpm пакеты то у него член был 10 см.
> > > А когда он будет собирать из gear то уже на следующий день член будет 11 см!
> > > По-моему, неплохая прибавка.
> > 
> > Особенно забавно будет, если мантейнер - девушка. ;)
> 
> У неё увеличится грудь! =)
Ещё немного, и можно будет выставлять возрастной ценз на попадание в
тим...

-- 
  Alexey "Ktirf" Rusakov
  Project Manager
  ALT Linux

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

Re: [devel] [OT] ALT: Liberte, egalite, fraternite ou la Mort?

[Anton Farygin]

Alexey Rusakov пишет:
> В Втр, 03/03/2009 в 11:21 +0300, Grigory Batalov пишет:
>> On Tue, 03 Mar 2009 09:20:48 +0300
>> Anton Farygin wrote:
>>
>>>>>> 	Мне не нравится, лишние телодвижения. Но даже я со своим вечным нытьем 
>>>>>> понимаю что политику партии не изменить, теперь будет git и только так. 
>>>>>> Этот механизм осваивать придется, если я хочу что-то дальше заливать.
>>>>> Ещё имейте в виду, что осваивая новые технологии вы повышаете свою капитализацию
>>>>> на рынке труда =)
>>>> Но самое главное, что переход на gear может увеличить размер полового члена.
>>>> Например, когда мейнтейнер собирал src.rpm пакеты то у него член был 10 см.
>>>> А когда он будет собирать из gear то уже на следующий день член будет 11 см!
>>>> По-моему, неплохая прибавка.
>>> Особенно забавно будет, если мантейнер - девушка. ;)
>> У неё увеличится грудь! =)
> Ещё немного, и можно будет выставлять возрастной ценз на попадание в
> тим...

Весна...

Re: [devel] ACL in branches

[Alexey Tourbin]

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

On Tue, Mar 03, 2009 at 09:50:23AM +0300, Денис Смирнов wrote:
> On Tue, Mar 03, 2009 at 08:00:33AM +0300, Алексей Турбин wrote:
> AT> Просто разводили демагогию что бранчи это намного стабильнее сизифа
> AT> потому что там неизвестно почему но с умным видом.  А теперь почва
> AT> для демагогии стала уменьшаться как шагреневая кожа.
> AT> Заработала проверка на устанавливаемость пакетов!
> 
> При нынешней технологии разработки -- бранчи не стабильнее Сизифа, они
> просто более протухшие :)

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

Тестовая пересборка пакетов пока не реализована.  Она может брать очень
много времени (=бесконечно с точки зрения наших реалий).  Можно как-то
справиться и с этим.

> Это плохо. Для выпуска дистрибутивов нужна стабильность.

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

> Под стабильностью я подразумевая хотя бы:
> 
> - предсказуемые и заранее документированные изменения (то бишь когда
>   сначала все узнают о том что что-то изменится серьезное, а потом оно
>   изменится, это шпилька в адрес нашего инсталлятора);

С одной стороны, никто никому не мешает писать анонсы.  Мейнтейнерам
надо взять за правило, что при любых глобальных/ значительных изменениях
надо писать в sisyphus (если это касается в основном пользователей), а
также в devel (если это касается и разработчиков).

Также (с другой стороны) надо понимать, что проблема изменений --
сложная.  Бывают разные типы изменений.  Например, проблемы, которых
не существует при первой установки пакета, они могут проявиться при
обновлении старого пакета.  Автоматика пока умеет тестировать только
установку пакетов с нуля.  Обновляемость, особенно с позапрошлых версий
(а не с предыдущих) тестировать гораздо сложнее.

> - ручная протестированность;

Что такое ручная протестированность?  Есть смысл что-то тестировать
вручную когда есть рельные специфические задачи и когда человек
заинтересован и понимает что там к чему происходит.

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

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

Re: [devel] [OT] ALT: Liberte, egalite, fraternite ou la Mort?

[Alexey Tourbin]

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

On Tue, Mar 03, 2009 at 11:35:35AM +0300, Alexey Rusakov wrote:
> В Втр, 03/03/2009 в 11:21 +0300, Grigory Batalov пишет:
> > > > Но самое главное, что переход на gear может увеличить размер полового члена.
> > > > Например, когда мейнтейнер собирал src.rpm пакеты то у него член был 10 см.
> > > > А когда он будет собирать из gear то уже на следующий день член будет 11 см!
> > > > По-моему, неплохая прибавка.
> > > 
> > > Особенно забавно будет, если мантейнер - девушка. ;)
> > 
> > У неё увеличится грудь! =)
> Ещё немного, и можно будет выставлять возрастной ценз на попадание в
> тим...

Прокатилась дурная слава что похабник я и скандалист!

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

Re: [devel] ACL in branches

[Dmitriy M. Maslennikov]

3 марта 2009 г. 18:16 пользователь Alexey Tourbin <at@altlinux.ru> написал:
>> - ручная протестированность;
>
> Что такое ручная протестированность?  Есть смысл что-то тестировать
> вручную когда есть рельные специфические задачи и когда человек
> заинтересован и понимает что там к чему происходит.
>
> А если сидит один человек и вручную тестирует всё сразу, то это имеет
> мало смысла.  Это человек это получается такая умная обезьяна.  Обезьяна
> сможет поверхностно убедиться в работоспособности лишь небольшого числа
> вещей, которые на виду.
Для меня это означает, что в течение гарантированного интервала
времени (например 1 месяц) на этом пакете не было ни одного бага от
пользователей ALTLinux. Хотелось бы, чтобы пакеты попадали в бранч
именно после ручного тестирования или они не нужны вообще.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] ACL in branches

[Alexey Tourbin]

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

On Tue, Mar 03, 2009 at 07:13:09PM +0300, Dmitriy M. Maslennikov wrote:
> 3 марта 2009 г. 18:16 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> >> - ручная протестированность;
> >
> > Что такое ручная протестированность?  Есть смысл что-то тестировать
> > вручную когда есть рельные специфические задачи и когда человек
> > заинтересован и понимает что там к чему происходит.
> >
> > А если сидит один человек и вручную тестирует всё сразу, то это имеет
> > мало смысла.  Это человек это получается такая умная обезьяна.  Обезьяна
> > сможет поверхностно убедиться в работоспособности лишь небольшого числа
> > вещей, которые на виду.
> Для меня это означает, что в течение гарантированного интервала
> времени (например 1 месяц) на этом пакете не было ни одного бага от
> пользователей ALTLinux. Хотелось бы, чтобы пакеты попадали в бранч
> именно после ручного тестирования или они не нужны вообще.

Не бывает ручного тестирования, которое даёт реально много.
В следующем смысле.

Понимаете, Вы тестируете не только то, что Вы залили, а Вы тестируете
сложную комбинацию того что Вы залили и что было до этого.  То есть
всегда будет две части: Ваш код и чужой код; и комбинация, в котрой
идёт тестирование.

Есть смысл тестировать код, который влияет непосредственно.
Повлиять на чужой код шансов меньше.

Кроме того, само понятие "комбинации" нашего кода и чужого кода оно тоже
не очедь однозначное.  Бывает (непротиворечивая) build-time комбинация
и runtime комбинация.  Всего этих комбинаций может быть очень много, и
все их протестировать более-менее нельзя.

Поэтому имеет смысл следующий подход к тестированию вручную.
1) Обновляем хост-систему до текущего репозитария (dist-upgrade).
2) Собираем пакет на текущем репозитарии.
3) Ставим собранный пакет в хост-систему и думаем работает он или нет.
4) Отправляем пакет на сборку.

Больше чем это сделать почти что ничего нельзя.

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

Re: [devel] ACL in branches

[Michael Shigorin]

On Sun, Mar 01, 2009 at 12:15:25AM +0300, Dmitry V. Levin wrote:
> Я полагаю, что освободившееся время мантейнеры бранчей смогут
> использовать для более конструктивных дел, чем закат солнца
> вручную.  Думаю что корректировать ACL не займёт много времени.
> Совсем отменить ACL при том, что пакеты обрабатываются и
> публикуются в _полностью_автоматическом_ режиме, не
> представляется возможным.

OK, принято.

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

Re: [devel] ACL in branches

[Michael Shigorin]

On Tue, Mar 03, 2009 at 06:16:36PM +0300, Alexey Tourbin wrote:
> > Это плохо. Для выпуска дистрибутивов нужна стабильность.
> Стабильность -- это демагогия.  Впрочем, когда это понятие
> уточняют, как сейчас, то есть о чем говорить.

* данность: люди делают/замечают/исправляют ошибки
* стабильность -- отношение скорости исправления
  обнаруженных проблем к скорости изменений

Так устроит для начала? (см. тж. google://"change management")

> > - ручная протестированность;
> Что такое ручная протестированность?  Есть смысл что-то
> тестировать вручную когда есть рельные специфические задачи и
> когда человек заинтересован и понимает что там к чему
> происходит.

Ага.  Т.е. когда получается краткая характеристика комплексной
слабоформализуемой ситуации -- вида "новый openldap с hdb намного
стабильнее старого с bdb" -- на основании практического опыта
тестирования и использования в работе.

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

Re: [devel] ACL in branches

[Michael Shigorin]

On Mon, Mar 02, 2009 at 11:00:47PM +0300, Alexey Tourbin wrote:
> Нет причины, почему бранч должен быть стабильнее Сизифа.

Это не так.

На бранчах по факту меньше скорость изменений (это измеримо)
и субъективно -- наблюдается несколько иное отношение к
заливаемому, по крайней мере не наблюдаю "ну залей и посмотри,
это ж сизиф".

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

И это тоже.  Плюс IMO существенно различающаяся по охвату
(в т.ч. железа, задач и их комбинаций) аудитория.

> Нет причины, почему бранч должен быть стабильнее Сизифа.

Лёш, снимай свои чугуниевые заслонки. :)

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

Re: [devel] ACL in branches

[Alexey Tourbin]

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

On Tue, Mar 03, 2009 at 07:08:29PM +0200, Michael Shigorin wrote:
> On Mon, Mar 02, 2009 at 11:00:47PM +0300, Alexey Tourbin wrote:
> > Нет причины, почему бранч должен быть стабильнее Сизифа.
> 
> Это не так.
> На бранчах по факту меньше скорость изменений (это измеримо)

Ну и как измерять скорость изменений?  То есть формального признака нет,
а есть такие духовные предчувствия что вроде река Сизиф должна течь со
скоростью 20 км/ч а река Бранч должна течь со скоростью 2 км/ч.

И чем плохо что идут изменения, если они в то же самое время
транзакционно "закрывают" все несовместимости?

> и субъективно -- наблюдается несколько иное отношение к
> заливаемому, по крайней мере не наблюдаю "ну залей и посмотри,
> это ж сизиф".

С моей колокольни это как раз демагогия -- рассуждать кто с каким
отношением куда залил какой пакет.  С моей колокольни надо уметь
проверять какие условия выполняются а какие не выполняются.

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

Тестирование вручную это сложный вопрос, я ещё не подготовился.
Мне кажется что большую половину тестирования "вручную" можно выполнять
автоматически.  А меньшую половину автоматически протестировать нельзя,
но это требует очень квалифированного тестера, а не обезьяны.

> > Нет причины, почему бранч должен быть стабильнее Сизифа.
> Лёш, снимай свои чугуниевые заслонки. :)

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

Re: [devel] ACL in branches

[Dmitriy M. Maslennikov]

3 марта 2009 г. 19:27 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> Не бывает ручного тестирования, которое даёт реально много.
> В следующем смысле.
>
> Понимаете, Вы тестируете не только то, что Вы залили, а Вы тестируете
> сложную комбинацию того что Вы залили и что было до этого.  То есть
> всегда будет две части: Ваш код и чужой код; и комбинация, в котрой
> идёт тестирование.
>
> Есть смысл тестировать код, который влияет непосредственно.
> Повлиять на чужой код шансов меньше.
>
> Кроме того, само понятие "комбинации" нашего кода и чужого кода оно тоже
> не очедь однозначное.  Бывает (непротиворечивая) build-time комбинация
> и runtime комбинация.  Всего этих комбинаций может быть очень много, и
> все их протестировать более-менее нельзя.
Скажем так, пакету, который "заработал без проблем" у 50 сисадминов я
доверяю больше, чем пакету, который прошел все имеющиеся на текущий
момент проверки в girar-builder. И мне глубоко наплевать насколько это
мнение формально правильнее. Думаю, что не только мне. Возможно в вашу
модель вкралась ошибка?

Постулат: установка и эксплуатация пакета в течение месяца на 50
рабочих станциях гарантированно выявляет не меньше ошибок, чем все
наши автоматические тесты. Кроме того, сочетание двух методик
(автоматическое и ручное тестирование добровольцами) математически
точно выявляет не меньше ошибок, чем одно только автоматическое
тестирование.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] ACL in branches

[Alexey Tourbin]

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

On Tue, Mar 03, 2009 at 09:21:07PM +0300, Dmitriy M. Maslennikov wrote:
> 3 марта 2009 г. 19:27 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> > Не бывает ручного тестирования, которое даёт реально много.
> > В следующем смысле.
> >
> > Понимаете, Вы тестируете не только то, что Вы залили, а Вы тестируете
> > сложную комбинацию того что Вы залили и что было до этого.  То есть
> > всегда будет две части: Ваш код и чужой код; и комбинация, в котрой
> > идёт тестирование.
> >
> > Есть смысл тестировать код, который влияет непосредственно.
> > Повлиять на чужой код шансов меньше.
> >
> > Кроме того, само понятие "комбинации" нашего кода и чужого кода оно тоже
> > не очедь однозначное.  Бывает (непротиворечивая) build-time комбинация
> > и runtime комбинация.  Всего этих комбинаций может быть очень много, и
> > все их протестировать более-менее нельзя.

> Скажем так, пакету, который "заработал без проблем" у 50 сисадминов я
> доверяю больше, чем пакету, который прошел все имеющиеся на текущий

Он сегодня у них заработал, а завтра они сделали dist-upgrade и у них
всё отвалилось.  При том, что вроде бы ничего специфического у них не
обновилось.  Вы всё ещё не понимаете, что в момент сборки пакета
существовала специфическая build-time комбинация потенциально влияющих
компонентов; а в момент запуска существует уже иная специфическая
runtime комбинация влияющих компонентов?

Вам кажется что если админы протестировали то это уже стопудово
как минимум на месяц или два?

Мне тогда не понятно, что именно Вы хотите протестировать.

> момент проверки в girar-builder. И мне глубоко наплевать насколько это
> мнение формально правильнее. Думаю, что не только мне. Возможно в вашу
> модель вкралась ошибка?

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

	И нет исхода мне!
	Ох, тяжко, тяжко мне!
	Тяжко сознанье бессилья моего...

> Постулат: установка и эксплуатация пакета в течение месяца на 50
> рабочих станциях гарантированно выявляет не меньше ошибок, чем все
> наши автоматические тесты. Кроме того, сочетание двух методик
> (автоматическое и ручное тестирование добровольцами) математически
> точно выявляет не меньше ошибок, чем одно только автоматическое
> тестирование.

Тестируйте вручную, как я Вам сказал.
Лушче ничего не будет.

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

Re: [devel] ACL in branches

[Dmitriy M. Maslennikov]

3 марта 2009 г. 21:47 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> Он сегодня у них заработал, а завтра они сделали dist-upgrade и у них
> всё отвалилось.  При том, что вроде бы ничего специфического у них не
> обновилось.  Вы всё ещё не понимаете, что в момент сборки пакета
> существовала специфическая build-time комбинация потенциально влияющих
> компонентов; а в момент запуска существует уже иная специфическая
> runtime комбинация влияющих компонентов?
Следовательно те компоненты, которые портят работоспособность других
после обновления не пройдут тестирование. Скажем так, если у меня есть
работающий apache, а завтра вышло обновление openssl, которое его
ломает, то вероятность, что за месяц это заметять и повесят баг на
openssl довольно высока. В этом случае такое плохое обновление не
должно попасть в стабильный бранч, что всем и надо. Сейчас же в бранч
попадет, что угодно, лишь бы удовлетворяло довольно слабым (но тем не
менее весьма полезным) проверкам, лишь бы не поломалась обновляемость.
А у мне сервера не гарантированно обновлять надо, а надо, чтобы они
работали. Вот и думай, что лучше - критическая уязвимость в openssl
или никем не проверенное обновление, которое, спасибо конечно,
гарантированно произойдет, но вот заработает ли то, что обновилось -
это дело десятое, ведь математически работоспособность проверить
нельзя, так и пытаться не стоит по вашем рассуждениям.

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

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

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

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] ACL in branches

[Evgeny Sinelnikov]

Здравствуйте,

3 марта 2009 г. 22:08 пользователь Dmitriy M. Maslennikov
<maslennikovdm@gmail.com> написал:
> 3 марта 2009 г. 21:47 пользователь Alexey Tourbin <at@altlinux.ru> написал:
>> Он сегодня у них заработал, а завтра они сделали dist-upgrade и у них
>> всё отвалилось.  При том, что вроде бы ничего специфического у них не
>> обновилось.  Вы всё ещё не понимаете, что в момент сборки пакета
>> существовала специфическая build-time комбинация потенциально влияющих
>> компонентов; а в момент запуска существует уже иная специфическая
>> runtime комбинация влияющих компонентов?
> Следовательно те компоненты, которые портят работоспособность других
> после обновления не пройдут тестирование. Скажем так, если у меня есть
> работающий apache, а завтра вышло обновление openssl, которое его
> ломает, то вероятность, что за месяц это заметять и повесят баг на
> openssl довольно высока. В этом случае такое плохое обновление не
> должно попасть в стабильный бранч, что всем и надо. Сейчас же в бранч
> попадет, что угодно, лишь бы удовлетворяло довольно слабым (но тем не
> менее весьма полезным) проверкам, лишь бы не поломалась обновляемость.

Ну, я так понимаю, что всё дело в вероятностях... Вероятность того,
что одни и те же исходники будут собраны по разному в разных сборочных
средах есть, и, в частности, зависит от не явных, вычисляемых, опций
сборки. Тем не менее на заданном наборе сборочных сред, вероятность
получения багов определяется именно исходниками... Исходники, как
генетический код, ничего другого всё равно не получится :) Видимо этим
определяется некоторая повторяемость результатов в Gentoo ;)

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

Кстати, раз уж зашло про стабильность, безопасность, уязвимости и
openssl... Пример, можно сказать, из жизни... В бранче 4.1 сейчас
лежит openssl-0.9.8d... У меня было и сохраняется желание получить в
нём поддержку kerberos. Но его там решено было оставить, как есть, ибо
вдруг его знает... не хочется ведь подставлять всех юзеров бранча... С
другой стороны, если бы лежала новая сборка рядом с бранчем в
отдельном репозитории, то в течении некоторого периода тестирования
можно было бы централизованно выявить возможные проблемы. А так
валяется он у меня такая сборка в RPMS.hasher и толку?

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

В плане же влияния сброчной среды я могу утверждать, что изменения в
бранче за полгода практически никакого влияния на качество бинарного
результата по вопросу сборки openssl+kerberos не повлияли... Из чего
следует противоположный вывод относительно целесообразности
тестирования отдельных дополнительных репозиториев, в случае
вероятностной оценки, по сравнению с аналитической. Поскольку
аналитика срезает разницу между существенными и не существенными
изменениями сборочной среды, для сборки заданного пакета, в заданный
период времени.

В плане же безопасности, я внёс в новые варианты своей сборки текущие
исправления, в частности CVE-2008-5077 и CVE-2007-4995, но передо мной
возникает ещё одна диллема... Вроде как два варианта (с исправлениями
с kerberos и исправлениями без kerberos) тестировать некогда, а
обновить сборку в бранче всё же стоит...
Вот ссылка на ветку libssl6:
http://git.altlinux.org/people/sin/packages/openssl.git?p=openssl.git;a=shortlog;h=refs/heads/libssl6

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

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

>> Мне тогда не понятно, что именно Вы хотите протестировать.

Хоть что-то, что по адекватным причинам сдерживает обновление пакета
или набора пакетов в бранчах или сизифе. Например, openssl с
поддержкой kerberos в бранче 4.1

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

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

>>> Постулат: установка и эксплуатация пакета в течение месяца на 50
>>> рабочих станциях гарантированно выявляет не меньше ошибок, чем все
>>> наши автоматические тесты. Кроме того, сочетание двух методик
>>> (автоматическое и ручное тестирование добровольцами) математически
>>> точно выявляет не меньше ошибок, чем одно только автоматическое
>>> тестирование.
>>
>> Тестируйте вручную, как я Вам сказал.

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

>> Лушче ничего не будет.
> Только один я протестировать все не могу. А тестировать всем
> сообществом не получается: пакеты попадают в основные репозитарии
> сразу после сборки. Сейчас пакеты тестироет только мантейнер у себя.
> Зачастую невнимательно и недолго. Некоторый отстойник для тестирования
> кандидатов на поступление в репозитарий был бы очень уместен. Кроме
> того, как уже писалось в эту рассылку это не портит вашей идеи о
> атомарной операции сборки-выкладывания пакета, если после тестовой
> сборки пакета сохранить его сборочную среду, а перед выкладыванием
> произвести пересборку и убедиться, что она не изменилась за время
> тестирования - иначе пересборка и повторное тестирование.
>

Примерно так... Мне кажется, что дело не столько в несознательности,
сколько в отсутствии инфраструктуры для совместного тестирования...
Одного Сизифа мне кажется, что уже мало... Когда возникает вопрос о
сборке обновления в сизиф, мэйнтейнер может оказать перед диллемой -
либо слать в сизиф полупроверенный вариант, либо пока подождать. В
результате мы можем получить и часто получаем пакеты полурабочие или
пока ещё старые...


-- 
Sin (Sinelnikov Evgeny)

Re: [devel] ACL in branches

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

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

On Tue, Mar 03, 2009 at 09:47:52PM +0300, Алексей Турбин wrote:

AT> Он сегодня у них заработал, а завтра они сделали dist-upgrade и у них
AT> всё отвалилось.  При том, что вроде бы ничего специфического у них не
AT> обновилось.  Вы всё ещё не понимаете, что в момент сборки пакета
AT> существовала специфическая build-time комбинация потенциально влияющих
AT> компонентов; а в момент запуска существует уже иная специфическая
AT> runtime комбинация влияющих компонентов?
AT> Вам кажется что если админы протестировали то это уже стопудово
AT> как минимум на месяц или два?
AT> Мне тогда не понятно, что именно Вы хотите протестировать.

Это ортогональные тесты.

Я могу сейчас сделать пакет который будет идеален с точки зрения упаковки,
обновления, и т.д. Только вот он будет 1 раз из 100 запусков делать dd
if=/dev/zero of=/dev/sda.

Пожалуйста, изобрети такую систему тестирования которая позволит ловить
такие пакеты.

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

Пятница -- полет нормальный.

В понедельник подъем по тревоге -- зафиксировано больше 20-и падений
сервиса за несколько минут. Я в шоке, ничего не понимаю, тестирование же
прошло успешно! Делаю откат. Клиент смотрит злобным взглядом и дает понять
что если я не объясню что произошло -- они меня прямо в серверной повесят.

Разбор полетов показал что в этой сборке была ошибка вендора. Которая
проявлялась один день в месяц с лишним. Связанная с обработкой даты. И в
этот конкретный день попадали мнооооого серверов с астериском :)

Если бы эта сборка была кем-то протестирована в течении полутора месяцев
-- ошибка была бы выявлена.

>> момент проверки в girar-builder. И мне глубоко наплевать насколько это
>> мнение формально правильнее. Думаю, что не только мне. Возможно в вашу
>> модель вкралась ошибка?
AT> В нашу модель вкралась ужасная ошибка!  Ужас прямо, всё какой-то загон
AT> и ужасные ошибки, только людям голову морочу.  Что мол то да сё, втираю
AT> какую-то несусветную муть, а людям-то православным всего лишь надо, чтобы
AT> пакеты у них работали.
AT>	И нет исхода мне!
AT>	Ох, тяжко, тяжко мне!
AT>	Тяжко сознанье бессилья моего...

:)

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

Есть еще целый пласт задач которые роботу поймать сложнее чем человеку.

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

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

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

С другой стороны есть люди, которые владеют какой-то частю этого
оборудования. Они ставят и говорят "работает! ура!" "не работает!
кошмар!", и это позволяет решать проблемы.

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

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

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

Re: [devel] ACL in branches

[Evgeny Sinelnikov]

4 марта 2009 г. 9:43 пользователь Денис Смирнов <mithraen@altlinux.ru> написал:
> On Tue, Mar 03, 2009 at 09:47:52PM +0300, Алексей Турбин wrote:
>
> AT> Он сегодня у них заработал, а завтра они сделали dist-upgrade и у них
> AT> всё отвалилось.  При том, что вроде бы ничего специфического у них не
> AT> обновилось.  Вы всё ещё не понимаете, что в момент сборки пакета
> AT> существовала специфическая build-time комбинация потенциально влияющих
> AT> компонентов; а в момент запуска существует уже иная специфическая
> AT> runtime комбинация влияющих компонентов?
> AT> Вам кажется что если админы протестировали то это уже стопудово
> AT> как минимум на месяц или два?
> AT> Мне тогда не понятно, что именно Вы хотите протестировать.
>
> Это ортогональные тесты.
>
> Я могу сейчас сделать пакет который будет идеален с точки зрения упаковки,
> обновления, и т.д. Только вот он будет 1 раз из 100 запусков делать dd
> if=/dev/zero of=/dev/sda.
>
> Пожалуйста, изобрети такую систему тестирования которая позволит ловить
> такие пакеты.
>
> Могу рассказать другой, уже реальный пример из жизни. Обновлял я как-то
> клиенту Asterisk. Все делали правильно -- работа в четверг вечером,
> планово все погасили, обновили, протестировали -- полет нормальный.
>
> Пятница -- полет нормальный.
>
> В понедельник подъем по тревоге -- зафиксировано больше 20-и падений
> сервиса за несколько минут. Я в шоке, ничего не понимаю, тестирование же
> прошло успешно! Делаю откат. Клиент смотрит злобным взглядом и дает понять
> что если я не объясню что произошло -- они меня прямо в серверной повесят.
>
> Разбор полетов показал что в этой сборке была ошибка вендора. Которая
> проявлялась один день в месяц с лишним. Связанная с обработкой даты. И в
> этот конкретный день попадали мнооооого серверов с астериском :)
>
> Если бы эта сборка была кем-то протестирована в течении полутора месяцев
> -- ошибка была бы выявлена.
>
>>> момент проверки в girar-builder. И мне глубоко наплевать насколько это
>>> мнение формально правильнее. Думаю, что не только мне. Возможно в вашу
>>> модель вкралась ошибка?
> AT> В нашу модель вкралась ужасная ошибка!  Ужас прямо, всё какой-то загон
> AT> и ужасные ошибки, только людям голову морочу.  Что мол то да сё, втираю
> AT> какую-то несусветную муть, а людям-то православным всего лишь надо, чтобы
> AT> пакеты у них работали.
> AT>     И нет исхода мне!
> AT>     Ох, тяжко, тяжко мне!
> AT>     Тяжко сознанье бессилья моего...
>
> :)
>
> Да, людям нужно чтобы работало. Системы автоматизированного тестирования
> которые ты пишешь решают целый пласт задач (причем, что характерно, таких
> которые _человеку_ поймать куда сложнее чем роботу).
>
> Есть еще целый пласт задач которые роботу поймать сложнее чем человеку.
>
> Создание инфраструктуры для полностью автоматического тестирования не
> только по формальным признакам, но и работоспособности -- это тоже
> интересная и полезная задача. Но _полностью_ нерешаемая принципиально.
>
> Да, я был бы рад если бы мог написать ряд скриптов описывающих логику
> тестирования, и чтобы после сборки в Сизифе пакет проходил ряд таких
> тестов. Это было бы хорошо и полезно. Но, увы, это тоже решит далеко не
> все проблемы.
>
> Скажем сейчас я не могу обеспечивть полноценное даже ручное тестирование
> Asterisk элементарно из-за отсутствие необходимого стенда. А стенд сделать
> который позволит его _более-менее_ полноценно протестировать стоит десятки
> килобаксов. _Полноценно_ -- несколько миллионов баксов. Хотя бы из-за того
> что тестировать надо совместимость по протоколам с целым списком
> оборудования, у которого очень страшные ценники. И что теперь мне делать,
> удавиться?
>
> С другой стороны есть люди, которые владеют какой-то частю этого
> оборудования. Они ставят и говорят "работает! ура!" "не работает!
> кошмар!", и это позволяет решать проблемы.
>
+1

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


-- 
Sin (Sinelnikov Evgeny)

Re: [devel] ACL in branches

[REAL]

Dmitriy M. Maslennikov пишет:
> Только один я протестировать все не могу. А тестировать всем
> сообществом не получается: пакеты попадают в основные репозитарии
> сразу после сборки. Сейчас пакеты тестироет только мантейнер у себя.

Это как это? Я вот собирал некоторое время назад GROMACS. Как бы я его 
протестировал у себя, на одной машине, и рядом даже второй не 
предвидится? Так не бывает. Дал товарищам ссылку, они поставили у 
себя, погоняли несколько дней, дали добро... Всё, можно и в бранч 
ложить. А Сизиф - как раз для того, чтобы такие товарищи могли у себя 
поставить и потестировать.

Так что Ваша модель - лишь частный случай.

-- 

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

Re: [devel] ACL in branches

[Evgeny Sinelnikov]

4 марта 2009 г. 11:28 пользователь REAL <root@mmedia2.kemsu.ru> написал:
> Dmitriy M. Maslennikov пишет:
>>
>> Только один я протестировать все не могу. А тестировать всем
>> сообществом не получается: пакеты попадают в основные репозитарии
>> сразу после сборки. Сейчас пакеты тестироет только мантейнер у себя.
>
> Это как это? Я вот собирал некоторое время назад GROMACS. Как бы я его
> протестировал у себя, на одной машине, и рядом даже второй не предвидится?
> Так не бывает. Дал товарищам ссылку, они поставили у себя, погоняли
> несколько дней, дали добро... Всё, можно и в бранч ложить. А Сизиф - как раз
> для того, чтобы такие товарищи могли у себя поставить и потестировать.
>
> Так что Ваша модель - лишь частный случай.

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

Не всегда, обычно крайне редко, можно найти рядом коллегу, который
занят той же проблемой.. Кроме того можно просто не знать, что он ей
тоже занимается... Неужели вы считаете, что всё это частный случай?


-- 
Sin (Sinelnikov Evgeny)

Re: [devel] ACL in branches

[Dmitriy M. Maslennikov]

4 марта 2009 г. 11:28 пользователь REAL <root@mmedia2.kemsu.ru> написал:
> Это как это? Я вот собирал некоторое время назад GROMACS. Как бы я его
> протестировал у себя, на одной машине, и рядом даже второй не предвидится?
> Так не бывает.
Еще как бывает! Бывает что нет свободной/подходящей машины. Бывает,
что двух-трех машин не достаточно, а надо бы сотню-другую
(тестирование драйверов видеокарт, например). Бывает, что нет
подходящей архитектуры железа. Бывает лень... Много чего бывает
такого, чего нет у мантейнера, но есть у коммунити.

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

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] ACL in branches

[REAL]

Dmitriy M. Maslennikov пишет:
>> Это как это? Я вот собирал некоторое время назад GROMACS. Как бы я его
>> протестировал у себя, на одной машине, и рядом даже второй не предвидится?
>> Так не бывает.
> Еще как бывает! Бывает что нет свободной/подходящей машины. Бывает,
> что двух-трех машин не достаточно, а надо бы сотню-другую
> (тестирование драйверов видеокарт, например). Бывает, что нет
> подходящей архитектуры железа. Бывает лень... Много чего бывает
> такого, чего нет у мантейнера, но есть у коммунити.

Не понял, а я про что? Я как раз про то и говорю. И пример привёл 
показательный - кластерный софт, который невозможно адекватно 
протестировать на локальной машине.

> мантейнера. А пока ваша, лишь частный (и редкий, к сожалению) случай
> сочетания пакета, который можно протестировать малыми силами и желания
> мантейнера это сделать.

Мой пример - пакет, который НЕВОЗМОЖНО протестировать малыми силами.

-- 

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

Re: [devel] ACL in branches

[Dmitriy M. Maslennikov]

4 марта 2009 г. 13:29 пользователь REAL <root@mmedia2.kemsu.ru> написал:
>>> Это как это? Я вот собирал некоторое время назад GROMACS. Как бы я его
>>> протестировал у себя, на одной машине, и рядом даже второй не
>>> предвидится?
>>> Так не бывает.
>> Еще как бывает! Бывает что нет свободной/подходящей машины. Бывает,
>> что двух-трех машин не достаточно, а надо бы сотню-другую
>> (тестирование драйверов видеокарт, например). Бывает, что нет
>> подходящей архитектуры железа. Бывает лень... Много чего бывает
>> такого, чего нет у мантейнера, но есть у коммунити.
>
> Не понял, а я про что? Я как раз про то и говорю. И пример привёл
> показательный - кластерный софт, который невозможно адекватно протестировать
> на локальной машине.
>
>> мантейнера. А пока ваша, лишь частный (и редкий, к сожалению) случай
>> сочетания пакета, который можно протестировать малыми силами и желания
>> мантейнера это сделать.
>
> Мой пример - пакет, который НЕВОЗМОЖНО протестировать малыми силами.
Значит мы просто не поняли друг друга)

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] ACL in branches

[Alexey Tourbin]

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

On Tue, Mar 03, 2009 at 07:04:00PM +0200, Michael Shigorin wrote:
> > > - ручная протестированность;
> > Что такое ручная протестированность?  Есть смысл что-то
> > тестировать вручную когда есть рельные специфические задачи и
> > когда человек заинтересован и понимает что там к чему
> > происходит.
> 
> Ага.  Т.е. когда получается краткая характеристика комплексной
> слабоформализуемой ситуации -- вида "новый openldap с hdb намного
> стабильнее старого с bdb" -- на основании практического опыта
> тестирования и использования в работе.

Есть такая проблема.  Автоматика не может сказать работают пакеты
"на самом деле" или нет.  Это пожалуй самая неприятная особенность
того чем мы занимаемся.  Внешне все может выглядеть благопристойно
а внутри там всё отвалилось и окрашенные гробы.  Которые не войдут
в царство небесное (пока как следует не запатчат их код по крайней
мере).

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

Но что я хотел сказать насчет "комплексной слабоформализуемой ситуации".
Оно почему в большей степени относится к сизифу а не бранчу?
Когда копирование пакетов открылось то большую часть пакетов просто
стали копировать из сизифа в бранч.  То есть каждый считает что он не
виноват.  А хто во всём виноват, если в кране нет воды?

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

Re: [devel] ACL in branches

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

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

On Tue, Mar 03, 2009 at 07:27:40PM +0300, Алексей Турбин wrote:

AT> Поэтому имеет смысл следующий подход к тестированию вручную.
AT> 1) Обновляем хост-систему до текущего репозитария (dist-upgrade).
AT> 2) Собираем пакет на текущем репозитарии.
AT> 3) Ставим собранный пакет в хост-систему и думаем работает он или нет.
AT> 4) Отправляем пакет на сборку.
AT> Больше чем это сделать почти что ничего нельзя.

Больше чем это -- тестирование пакета _несколькими_ людьми. Причем не
"ставится и смотрим", а "ставится на тестовый стенд, гоняется, потом
отправляется в production, там тоже гоняется". После того как несколько
человек это проделали можно с заметно большей уверенностью утверждать что
пакет работает (а не сегфолтится один из 10-и раз при запуске, например).

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

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

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

Re: [devel] ACL in branches

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

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

On Tue, Mar 03, 2009 at 06:16:36PM +0300, Алексей Турбин wrote:

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

И это -- очень хорошо.

AT> Тестовая пересборка пакетов пока не реализована.  Она может брать очень
AT> много времени (=бесконечно с точки зрения наших реалий).  Можно как-то
AT> справиться и с этим.

Да, и это -- тоже очень хорошо.

>> Это плохо. Для выпуска дистрибутивов нужна стабильность.
AT> Стабильность -- это демагогия.
AT> Впрочем, когда это понятие уточняют, как сейчас, то есть о чем говорить.

Сферической стабильности в вакууме на коде сложнее hello world добиться
вообще очень сложно. Но можно убедиться что с большой степенью вероятности
уровень надежности удовлетворительный (перевожу -- админа за apt-get
install этого пакета не уволят).

AT> С одной стороны, никто никому не мешает писать анонсы.  Мейнтейнерам
AT> надо взять за правило, что при любых глобальных/ значительных изменениях
AT> надо писать в sisyphus (если это касается в основном пользователей), а
AT> также в devel (если это касается и разработчиков).

Хорошо бы анонс видеть _за некоторое время_ до изменения. А не "все
сломали давайте чинить".

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

Мне этот эксперимент с использованием инсталлера в работе стоил очень
много нервов.

AT> Также (с другой стороны) надо понимать, что проблема изменений --
AT> сложная.  Бывают разные типы изменений.  Например, проблемы, которых
AT> не существует при первой установки пакета, они могут проявиться при
AT> обновлении старого пакета.  Автоматика пока умеет тестировать только
AT> установку пакетов с нуля.  Обновляемость, особенно с позапрошлых версий
AT> (а не с предыдущих) тестировать гораздо сложнее.

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

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

>> - ручная протестированность;
AT> Что такое ручная протестированность?  Есть смысл что-то тестировать
AT> вручную когда есть рельные специфические задачи и когда человек
AT> заинтересован и понимает что там к чему происходит.

Именно такая протестированность и нужна. То есть не просто "Вася Пупкин
взял и поигрался". А "некто поставил и пользуется в своей работе этим
пакетом, и при этом количество мата в адрес этой сборки пакета меньше чем
количество мата в адрес предыдущей сборки пакета".

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

Вещи которые может сделать обезъяна должен делать робот.

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

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

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

Re: [devel] ACL in branches

[Alexey Tourbin]

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

On Fri, Mar 06, 2009 at 07:19:46PM +0300, Денис Смирнов wrote:
> >> Это плохо. Для выпуска дистрибутивов нужна стабильность.
> AT> Стабильность -- это демагогия.
> AT> Впрочем, когда это понятие уточняют, как сейчас, то есть о чем говорить.
> 
> Сферической стабильности в вакууме на коде сложнее hello world добиться
> вообще очень сложно. Но можно убедиться что с большой степенью вероятности
> уровень надежности удовлетворительный (перевожу -- админа за apt-get
> install этого пакета не уволят).

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

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

То есть существует стык между формальными условиями и содержательными
требованиями.  И на этом стыке можно реализовать полезную автоматику.

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

> AT> С одной стороны, никто никому не мешает писать анонсы.  Мейнтейнерам
> AT> надо взять за правило, что при любых глобальных/ значительных изменениях
> AT> надо писать в sisyphus (если это касается в основном пользователей), а
> AT> также в devel (если это касается и разработчиков).
> 
> Хорошо бы анонс видеть _за некоторое время_ до изменения. А не "все
> сломали давайте чинить".

Ну а зачем всё сломать а потом давайте всё чинить?

> Поясняю -- я теперь стараюсь держать у себя срез 5.0 за определенное
> время. Потому как я месяц готовил дистр под клиента к релизу, и за два дня
> до этого самого релиза оказалось что разломали нафиг alterator-lilo,
> datetime. При этом где-то несовместимые изменения (лечится обновлением
> профиля), а где-то -- страшные баги, уровня "это даже не пытались
> запустить". И это -- в стабильном бранче.

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

> Мне этот эксперимент с использованием инсталлера в работе стоил очень
> много нервов.

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

> AT> Также (с другой стороны) надо понимать, что проблема изменений --
> AT> сложная.  Бывают разные типы изменений.  Например, проблемы, которых
> AT> не существует при первой установки пакета, они могут проявиться при
> AT> обновлении старого пакета.  Автоматика пока умеет тестировать только
> AT> установку пакетов с нуля.  Обновляемость, особенно с позапрошлых версий
> AT> (а не с предыдущих) тестировать гораздо сложнее.
> 
> Некоторые вещи можно тестировать автоматически и по поводу предсказуемости
> обновлений. Для этого нужна полная история всех пакетов, включая их
> зависимости и содержащиеся в них файлы. Целый ряд стандартных проблем при
> обновлении этим решается.

И какого же рода вещи таким образом можно протестировать?  И важно
чтобы проверка не лажалась, то есть чтобы уровень false positives был
не больше 0.1%.  Иначе мы просто будем зарубать нормальные пакеты.

> Другой пласт решается тем самым предлагаемым мной полиси на тему "если
> изменился soname -- поменяйте имя пакета, и не создавайте, пожалуйста,
> геморроя пользователю".

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

> >> - ручная протестированность;
> AT> Что такое ручная протестированность?  Есть смысл что-то тестировать
> AT> вручную когда есть рельные специфические задачи и когда человек
> AT> заинтересован и понимает что там к чему происходит.
> 
> Именно такая протестированность и нужна. То есть не просто "Вася Пупкин
> взял и поигрался". А "некто поставил и пользуется в своей работе этим
> пакетом, и при этом количество мата в адрес этой сборки пакета меньше чем
> количество мата в адрес предыдущей сборки пакета".

Возможна ли такая протестированность в предварительном режиме, перед
тем, как пакеты попадают в Сизиф?  У нас как процесс устроен:
предварительное тестирование, попадание пакета в сизиф, дальше широкое
тестирование (всем миром).  Вопрос в том что можно сделать на первой
стадии за конечное время.  Ответ в том что тут впрягается автоматика
которая отлавливает грубые нарушения.

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

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

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

Re: [devel] ACL in branches

[Dmitriy M. Maslennikov]

2009/3/6 Alexey Tourbin <at@altlinux.ru>:
> Во-вторых, что можно противопоставить автоматике?  Только
> квалифицированное тестирование вручную.  А квалифицированные тестеры
> которые хорошо разбираются во всякой специфике это либо сами
> разработчики либо прикладные специалисты.  Их просто не получится по
> количеству и по времени запрячь в какое-то предварительное тестирование
> перед выкладываением пакетов в сизиф.  Можно через какое-то время
> надеяться на feedback.  А автоматика работает достаточно быстро,
> и её легко запрячь на проверку предварительных условий.
>
> Ну я и говорю что стабильность это скорее демагогия.  Она вроде бы
> поддерживается на плохо формализуемом конвенциональном принципе "в
> бранчи не следует заливать экспериментальный софт".  Но его туда всё
> равно заливают.  Потому что каждый думает, что его пакет хороший и в
> проблемах не виноват.  Что тогда даёт этот бранч?  Если все эти
> конвенциональные соображения трудно сформулировать и трудно проверить.
>
> И что тогда можно придумать, чтобы всем было хорошо?
>
> И какого же рода вещи таким образом можно протестировать?  И важно
> чтобы проверка не лажалась, то есть чтобы уровень false positives был
> не больше 0.1%.  Иначе мы просто будем зарубать нормальные пакеты.
>
> Возможна ли такая протестированность в предварительном режиме, перед
> тем, как пакеты попадают в Сизиф?  У нас как процесс устроен:
> предварительное тестирование, попадание пакета в сизиф, дальше широкое
> тестирование (всем миром).  Вопрос в том что можно сделать на первой
> стадии за конечное время.  Ответ в том что тут впрягается автоматика
> которая отлавливает грубые нарушения.
Вот вам все и говорят здесь, что процесс не правильно устроен. Удобнее
было бы, если сначала собранные пакеты попадали в созданный специально
под задачу (например, обновление X-сервера) box или pocket, и
появлялся анонс: "тестируем X-сервер все, кому он интересен". Это
коренным образом отличается от дедала, так как в специальном покете
нет "мусора" из пакетов не относящихсяк делу. Если никто тестировать
не захотел, то это проблемы коммунити, если же выявлены проблемы, то
пакеты не принимаются и ничего ни у кого неожиданно не портят. Сейчас
мы просто пропускаем этап тестирования вообще. И даже не планируем его
в будущем, а просто пытаемся убедить все, что такой этап не нужен/не
возможен/бесполезен. Сейчас либо его организует каждый как хочет
(просит соседа, выкладывает в своем собственном репозитории и т. п.),
а единой инфраструктуры с анонсами, поиском, возможностью вешать баги
именно на pocket'ы просто нет. Поэтому все постоянно ломается и
репозитарий вцелом находится в перманентно разломанном виде.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] ACL in branches

[Alexey Tourbin]

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

On Sat, Mar 07, 2009 at 12:17:49PM +0300, Dmitriy M. Maslennikov wrote:
> 2009/3/6 Alexey Tourbin <at@altlinux.ru>:
> > Во-вторых, что можно противопоставить автоматике?  Только
> > квалифицированное тестирование вручную.  А квалифицированные тестеры
> > которые хорошо разбираются во всякой специфике это либо сами
> > разработчики либо прикладные специалисты.  Их просто не получится по
> > количеству и по времени запрячь в какое-то предварительное тестирование
> > перед выкладываением пакетов в сизиф.  Можно через какое-то время
> > надеяться на feedback.  А автоматика работает достаточно быстро,
> > и её легко запрячь на проверку предварительных условий.
> >
> > Ну я и говорю что стабильность это скорее демагогия.  Она вроде бы
> > поддерживается на плохо формализуемом конвенциональном принципе "в
> > бранчи не следует заливать экспериментальный софт".  Но его туда всё
> > равно заливают.  Потому что каждый думает, что его пакет хороший и в
> > проблемах не виноват.  Что тогда даёт этот бранч?  Если все эти
> > конвенциональные соображения трудно сформулировать и трудно проверить.
> >
> > И что тогда можно придумать, чтобы всем было хорошо?
> >
> > И какого же рода вещи таким образом можно протестировать?  И важно
> > чтобы проверка не лажалась, то есть чтобы уровень false positives был
> > не больше 0.1%.  Иначе мы просто будем зарубать нормальные пакеты.
> >
> > Возможна ли такая протестированность в предварительном режиме, перед
> > тем, как пакеты попадают в Сизиф?  У нас как процесс устроен:
> > предварительное тестирование, попадание пакета в сизиф, дальше широкое
> > тестирование (всем миром).  Вопрос в том что можно сделать на первой
> > стадии за конечное время.  Ответ в том что тут впрягается автоматика
> > которая отлавливает грубые нарушения.
> Вот вам все и говорят здесь, что процесс не правильно устроен. Удобнее
> было бы, если сначала собранные пакеты попадали в созданный специально
> под задачу (например, обновление X-сервера) box или pocket, и
> появлялся анонс: "тестируем X-сервер все, кому он интересен".

Желание тестировать пакеты перед выкладыванием конечно похвальное,
но это как бы слишком круто что ли.  У нас в день прходит около 100
пакетов (в сизиф).  В пиковые рабочие часы мы просто не успеваем их
собирать, несмотря на неплохие в целом показатели производительности
сборочнцы.  То есть всё равно очередь накапливается на час вперёд,
это если не брать очень сложных пакетов/заданий, которые появляются
относительно редко.

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

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

> Это
> коренным образом отличается от дедала, так как в специальном покете
> нет "мусора" из пакетов не относящихсяк делу. Если никто тестировать
> не захотел, то это проблемы коммунити, если же выявлены проблемы, то
> пакеты не принимаются и ничего ни у кого неожиданно не портят. Сейчас
> мы просто пропускаем этап тестирования вообще. И даже не планируем его
> в будущем, а просто пытаемся убедить все, что такой этап не нужен/не
> возможен/бесполезен.

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

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

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

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

Есть соображения насчёт модели репозитария, которые лишают карманную
инфраструктуру привлекательности.  Соображения следующие:

1) Репозитарий пакетов в каждый момент времени может находится только
в одном состоянии.
2) Возможны строго последовательные (сериализованные) переходы, при
которых репозитарий переходит из одного состояния в другое состояние.
3) Каждый переход должен быть подготовлен на текущем состоянии
репозитария.

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

Карманы почему плохо согласуются с моделью?  Потому что карманы дают
множество параллельных состояний.  Не факт, что эти параллельные
состояния удастся "состыковать" и привести к виду последовательных
согласовнных транзакций.

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

Re: [devel] ACL in branches

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

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

On Fri, Mar 06, 2009 at 08:20:09PM +0300, Алексей Турбин wrote:

AT> С помощью автоматики убедиться в "стабильности", надежности и
AT> работоспособности очень сложно.  Автоматика может проверять лишь
AT> некоторые заранее известные формальные условия.

Да.

AT> Но не всё так безнадёжно.  Во-первых, формальные условия в значительной
AT> степени отражают некоторые важные характеристики работоспособности.
AT> Например, анметы означают, что какой-то пакет просто не удастся
AT> установить без нарушений.  А "нарушение" связано с тем что пакету
AT> чего-то не хватает, и работать он не будет.  Если бы анметы означали
AT> что-то ещё, то просто были бы менее полезной информацией.
AT> То есть существует стык между формальными условиями и содержательными
AT> требованиями.  И на этом стыке можно реализовать полезную автоматику.

Да.

AT> Во-вторых, что можно противопоставить автоматике?  Только
AT> квалифицированное тестирование вручную.  А квалифицированные тестеры
AT> которые хорошо разбираются во всякой специфике это либо сами
AT> разработчики либо прикладные специалисты.  Их просто не получится по
AT> количеству и по времени запрячь в какое-то предварительное тестирование
AT> перед выкладываением пакетов в сизиф.  Можно через какое-то время
AT> надеяться на feedback.  А автоматика работает достаточно быстро,
AT> и её легко запрячь на проверку предварительных условий.

Еще ее можно запрячь на действия по событиям от пользователей. Т.е. баг в
багтрекере -- тоже ценная информация.

>> Хорошо бы анонс видеть _за некоторое время_ до изменения. А не "все
>> сломали давайте чинить".
AT> Ну а зачем всё сломать а потом давайте всё чинить?

Спроси это у тех кто так поступает :)

>> Поясняю -- я теперь стараюсь держать у себя срез 5.0 за определенное
>> время. Потому как я месяц готовил дистр под клиента к релизу, и за два дня
>> до этого самого релиза оказалось что разломали нафиг alterator-lilo,
>> datetime. При этом где-то несовместимые изменения (лечится обновлением
>> профиля), а где-то -- страшные баги, уровня "это даже не пытались
>> запустить". И это -- в стабильном бранче.
AT> Ну я и говорю что стабильность это скорее демагогия.  Она вроде бы
AT> поддерживается на плохо формализуемом конвенциональном принципе "в
AT> бранчи не следует заливать экспериментальный софт".  Но его туда всё
AT> равно заливают.  Потому что каждый думает, что его пакет хороший и в
AT> проблемах не виноват.  Что тогда даёт этот бранч?  Если все эти
AT> конвенциональные соображения трудно сформулировать и трудно проверить.

Вот о том и речь, что сейчас бранч -- это непонятно чем отличающееся от
Сизифа добро.

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

То что он оказался в Сизифе -- нормально. Но в бранч он должен попасть
только после прохождения тестирования в Сизифе.

>> Некоторые вещи можно тестировать автоматически и по поводу предсказуемости
>> обновлений. Для этого нужна полная история всех пакетов, включая их
>> зависимости и содержащиеся в них файлы. Целый ряд стандартных проблем при
>> обновлении этим решается.
AT> И какого же рода вещи таким образом можно протестировать?  И важно
AT> чтобы проверка не лажалась, то есть чтобы уровень false positives был
AT> не больше 0.1%.  Иначе мы просто будем зарубать нормальные пакеты.

Например -- пересечения по файлам между пакетами и отсутствие при этом
конфликтов на уровне rpm. Сейчас это проверяется repocop'ом, но это не
проверяется с учетом _истории_ пакета.

>> Другой пласт решается тем самым предлагаемым мной полиси на тему "если
>> изменился soname -- поменяйте имя пакета, и не создавайте, пожалуйста,
>> геморроя пользователю".
AT> Такого рода прикладную логику как раз реализовать несколько легче.
AT> Но и тут есть некоторые проблемы.  Нельзя четко отделить системные
AT> библиотеки от как бы вспомогательных библиотек.  Если у вспомогательной
AT> библиотеки меняется сонейм, и у этой библиотеки среди пакетов всего
AT> два-три клиента, тогда имя пакета можно не менять.  А если у библиотеки
AT> 100 или более клиентов, тогда менять имя пакета нужно практически
AT> безусловно.  А четкого критерия нет.

Есть случае когда точно менять можно -- если все пакеты которые requires
этот soname собираются из того же srpm.

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

>> Именно такая протестированность и нужна. То есть не просто "Вася Пупкин
>> взял и поигрался". А "некто поставил и пользуется в своей работе этим
>> пакетом, и при этом количество мата в адрес этой сборки пакета меньше чем
>> количество мата в адрес предыдущей сборки пакета".
AT> Возможна ли такая протестированность в предварительном режиме, перед
AT> тем, как пакеты попадают в Сизиф?  У нас как процесс устроен:
AT> предварительное тестирование, попадание пакета в сизиф, дальше широкое
AT> тестирование (всем миром).  Вопрос в том что можно сделать на первой
AT> стадии за конечное время.  Ответ в том что тут впрягается автоматика
AT> которая отлавливает грубые нарушения.

Увы нет. Эти тесты должны проходить когда пакет уже в Сизифе или любом
другом публичном репозитории.

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

:(

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

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

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

Re: [devel] ACL in branches

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

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

On Sat, Mar 07, 2009 at 01:39:59PM +0300, Алексей Турбин wrote:

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

Но в бранчи пакет должен перемещаться в тот момент, когда там известно что
нет критических проблем.

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

Гарантии никто и никогда не даст. Но факты уровня "а вот там rm -rf /* в
%pre" -- выловятся _гарантировано_. И меня это устраивает.

AT> Кстати, поэтому имеет смысл налаживать автоматическое тестирование 
AT> при сборке пакета, что-то типа 'make test'.  Пусть кто-то хочет
AT> разломать Ваш пакет, но у Вас при сборке выполняется 'make test'.
AT> Тогда облом 'make test' при тестовой пересборке является индикатором,
AT> что новый входящий пакет не согласуется с Вашим существующим пакетом.

Да, это хорошая практика. Но не все так можно протестировать. Во многих
случаях тест, это apt-get upgrade на некритичной машинке с последующими
матюками.

AT> 1) Репозитарий пакетов в каждый момент времени может находится только
AT> в одном состоянии.
AT> 2) Возможны строго последовательные (сериализованные) переходы, при
AT> которых репозитарий переходит из одного состояния в другое состояние.
AT> 3) Каждый переход должен быть подготовлен на текущем состоянии
AT> репозитария.

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

Это делает невозможным bootstrap без разлома репозитория.

AT> Карманы почему плохо согласуются с моделью?  Потому что карманы дают
AT> множество параллельных состояний.  Не факт, что эти параллельные
AT> состояния удастся "состыковать" и привести к виду последовательных
AT> согласовнных транзакций.

Перемещение из кармана в Сизиф -- это тоже транзакция.

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

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

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

Re: [devel] ACL in branches

[Alexey Rusakov]

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

В Сбт, 07/03/2009 в 15:57 +0300, Денис Смирнов пишет:
> >> Вещи которые может сделать обезъяна должен делать робот.
> AT> Не всегда.  Графические приложения сложно протестировать автоматически,
> AT> даже на минимальном уровне.  Иксовый протокол очень дубовый.  Грубо
> AT> говоря, можно лишь передавать нажатия клавиш в окно, и больше сделать
> AT> ничего нельзя.  Всякие там объекты, меню и т.п. существуют уже на уровне
> AT> тулкитов.
> 
> :(
Вообще-то это не такая уж проблема... По крайней мере для Gtk+
существует Accersizer и построенные на at-spi инспекторы интерфейсов...
Уверен, что для Qt тоже есть что-то подобное.

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

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

Re: [devel] ACL in branches

[Alexey Tourbin]

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

On Sat, Mar 07, 2009 at 09:02:24PM +0300, Денис Смирнов wrote:
> AT> 1) Репозитарий пакетов в каждый момент времени может находится только
> AT> в одном состоянии.
> AT> 2) Возможны строго последовательные (сериализованные) переходы, при
> AT> которых репозитарий переходит из одного состояния в другое состояние.
> AT> 3) Каждый переход должен быть подготовлен на текущем состоянии
> AT> репозитария.
> 
> AT> Последнее условие, в частности, запрещает копировать пакеты из одного
> AT> бранча в другой.
> 
> Это делает невозможным bootstrap без разлома репозитория.

А бутстрап даёт возможность _незаметно_ засадить трояна.
http://en.wikipedia.org/wiki/Backdoor_(computing)

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

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

Re: [devel] ACL in branches

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

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

On Sun, Mar 08, 2009 at 12:12:46AM +0300, Алексей Турбин wrote:

AT> А бутстрап даёт возможность _незаметно_ засадить трояна.
AT> http://en.wikipedia.org/wiki/Backdoor_(computing)
AT> Это накладывает определенные ограничения, в каких комбинациях пакеты
AT> должны попадать в репозитарий, и какого рода транзакции можно разрешить.
AT> А именно, сборку пакета нужно рассматривать как функцию исходников и
AT> содержимого сборочного чрута.  Тогда транзакция должна быть согласована
AT> по последовательности сборки пакетов: нельзя пропускать пакеты без
AT> пререквизитов.  На самом деле четкое определение дать не так просто,
AT> но идея должна быть понятна.

Я думаю вот что.

В момент перемещения транзакции в репозиторий при копировании образуется
некий временный репозиторий. В этом временном репозитории пакеты, которые
были добавлены/обнавлены транзакцией слияния pocket'а должны быть еще раз
пересобраны уже в этом репозитории.

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

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

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

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

Re: [devel] ACL in branches

[Alexey Rusakov]

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

В Пнд, 09/03/2009 в 01:32 +0300, Денис Смирнов пишет:
> On Sun, Mar 08, 2009 at 12:12:46AM +0300, Алексей Турбин wrote:
> 
> AT> А бутстрап даёт возможность _незаметно_ засадить трояна.
> AT> http://en.wikipedia.org/wiki/Backdoor_(computing)
> AT> Это накладывает определенные ограничения, в каких комбинациях пакеты
> AT> должны попадать в репозитарий, и какого рода транзакции можно разрешить.
> AT> А именно, сборку пакета нужно рассматривать как функцию исходников и
> AT> содержимого сборочного чрута.  Тогда транзакция должна быть согласована
> AT> по последовательности сборки пакетов: нельзя пропускать пакеты без
> AT> пререквизитов.  На самом деле четкое определение дать не так просто,
> AT> но идея должна быть понятна.
> 
> Я думаю вот что.
> 
> В момент перемещения транзакции в репозиторий при копировании образуется
> некий временный репозиторий. В этом временном репозитории пакеты, которые
> были добавлены/обнавлены транзакцией слияния pocket'а должны быть еще раз
> пересобраны уже в этом репозитории.
> 
> Таким образом мы по крайней мере гарантируем что в момент прохождения
> транзакции эти пакеты при пересборке в этом репозитории дают именно тот
> результат, который отправится в репозиторий.
Таким образом мы получаем, что те пакеты, которые мы тестировали в
покете, и те, которые в итоге попадают в репозиторий, собираются на
разных пакетных базах. За что боролись?

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

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

Re: [devel] ACL in branches

[Dmitriy M. Maslennikov]

9 марта 2009 г. 3:47 пользователь Alexey Rusakov <ktirf@altlinux.org> написал:
> Таким образом мы получаем, что те пакеты, которые мы тестировали в
> покете, и те, которые в итоге попадают в репозиторий, собираются на
> разных пакетных базах. За что боролись?
Таким образом мы гарантируем, что в репозитории не произошло
изменений, влияющих на интересующие нас пакеты. Если произошли -
повторное тестирование.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] ACL in branches

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

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

On Mon, Mar 09, 2009 at 03:47:31AM +0300, Alexey Rusakov wrote:

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

1. За то, чтобы не было _заведомо_ разломанного Сизифа. pocket при
использовании для таких целей -- не требует разламывать Сизиф с целью
bootstrap'а.

2. Баги которые не зависят от окружения в котором был собран пакет -- таки
могут быть выявлены. А их существенно больше чем багов зависящих от
окружения. Вообще говоря, в мире Linux каждая бага зависящая от окружения
это -- серьезная бага. Либо в самом приложении, либо в том самом
окружении, потому что такого быть не должно.

Пакет после тестовой пересборки должен работать нормально.

Кстати у нас не делается при тестовой пересборки сравнения получившегося
пакета с лежащим в репозитории хотя бы на уровне списка файлов в пакете и
provides/requires? Это могло бы заранее выявлять многие проблемы. По сути
такое различие может указывать на то, что пакет "почти" не пересобирается.

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

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


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

Re: [devel] ACL in branches

[Alexey Rusakov]

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

В Пнд, 09/03/2009 в 14:23 +0300, Денис Смирнов пишет:
> On Mon, Mar 09, 2009 at 03:47:31AM +0300, Alexey Rusakov wrote:
> 
> AR> Таким образом мы получаем, что те пакеты, которые мы тестировали в
> AR> покете, и те, которые в итоге попадают в репозиторий, собираются на
> AR> разных пакетных базах. За что боролись?
> 
> 1. За то, чтобы не было _заведомо_ разломанного Сизифа. pocket при
> использовании для таких целей -- не требует разламывать Сизиф с целью
> bootstrap'а.
А. Про bootstrap согласен, +1.

> 2. Баги которые не зависят от окружения в котором был собран пакет -- таки
> могут быть выявлены. А их существенно больше чем багов зависящих от
> окружения. Вообще говоря, в мире Linux каждая бага зависящая от окружения
> это -- серьезная бага. Либо в самом приложении, либо в том самом
> окружении, потому что такого быть не должно.
Багов вообще быть не должно, но они есть :) Самые неприятные баги
возникают, как известно, на стыках.

> Пакет после тестовой пересборки должен работать нормально.
> 
> Кстати у нас не делается при тестовой пересборки сравнения получившегося
> пакета с лежащим в репозитории хотя бы на уровне списка файлов в пакете и
> provides/requires? Это могло бы заранее выявлять многие проблемы. По сути
> такое различие может указывать на то, что пакет "почти" не пересобирается.
Одно изменение в хедере библиотеки может привести к изменению поведения
программы, и в заголовках RPM это никак не отразится. То есть это
"почти" - оно очень условное.

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

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

Re: [devel] ACL in branches

[Evgeny Sinelnikov]

9 марта 2009 г. 14:44 пользователь Alexey Rusakov <ktirf@altlinux.org> написал:
> В Пнд, 09/03/2009 в 14:23 +0300, Денис Смирнов пишет:
>> On Mon, Mar 09, 2009 at 03:47:31AM +0300, Alexey Rusakov wrote:
>>
>> AR> Таким образом мы получаем, что те пакеты, которые мы тестировали в
>> AR> покете, и те, которые в итоге попадают в репозиторий, собираются на
>> AR> разных пакетных базах. За что боролись?
>>
>> 1. За то, чтобы не было _заведомо_ разломанного Сизифа. pocket при
>> использовании для таких целей -- не требует разламывать Сизиф с целью
>> bootstrap'а.
> А. Про bootstrap согласен, +1.
>
>> 2. Баги которые не зависят от окружения в котором был собран пакет -- таки
>> могут быть выявлены. А их существенно больше чем багов зависящих от
>> окружения. Вообще говоря, в мире Linux каждая бага зависящая от окружения
>> это -- серьезная бага. Либо в самом приложении, либо в том самом
>> окружении, потому что такого быть не должно.
> Багов вообще быть не должно, но они есть :) Самые неприятные баги
> возникают, как известно, на стыках.
>
>> Пакет после тестовой пересборки должен работать нормально.
>>
>> Кстати у нас не делается при тестовой пересборки сравнения получившегося
>> пакета с лежащим в репозитории хотя бы на уровне списка файлов в пакете и
>> provides/requires? Это могло бы заранее выявлять многие проблемы. По сути
>> такое различие может указывать на то, что пакет "почти" не пересобирается.
> Одно изменение в хедере библиотеки может привести к изменению поведения
> программы, и в заголовках RPM это никак не отразится. То есть это
> "почти" - оно очень условное.
>

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

-- 
Sin (Sinelnikov Evgeny)

Re: [devel] ACL in branches

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

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

On Mon, Mar 09, 2009 at 02:44:46PM +0300, Alexey Rusakov wrote:

>> Пакет после тестовой пересборки должен работать нормально.
>> Кстати у нас не делается при тестовой пересборки сравнения получившегося
>> пакета с лежащим в репозитории хотя бы на уровне списка файлов в пакете и
>> provides/requires? Это могло бы заранее выявлять многие проблемы. По сути
>> такое различие может указывать на то, что пакет "почти" не пересобирается.
AR> Одно изменение в хедере библиотеки может привести к изменению поведения
AR> программы, и в заголовках RPM это никак не отразится. То есть это
AR> "почти" - оно очень условное.

Безусловно такая проверка не выявляет всех проблем.

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

Такой тест -- позволяет выявить некоторые баги.

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

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

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

Re: [devel] ACL in branches

[Led]

On Monday 09 March 2009 15:38:11 Денис Смирнов wrote:
> On Mon, Mar 09, 2009 at 02:44:46PM +0300, Alexey Rusakov wrote:
> >> Пакет после тестовой пересборки должен работать нормально.
> >> Кстати у нас не делается при тестовой пересборки сравнения получившегося
> >> пакета с лежащим в репозитории хотя бы на уровне списка файлов в пакете
> >> и provides/requires? Это могло бы заранее выявлять многие проблемы. По
> >> сути такое различие может указывать на то, что пакет "почти" не
> >> пересобирается.
>
> AR> Одно изменение в хедере библиотеки может привести к изменению поведения
> AR> программы, и в заголовках RPM это никак не отразится. То есть это
> AR> "почти" - оно очень условное.
>
> Безусловно такая проверка не выявляет всех проблем.
>
> Давайте не будем искать серебрянную пулю, а будет внедрять технологии
> облегчающие выявление и устранение багов.

Первая ("выявление") у нас значительно опережает вторую ("устранение"), 
поэтому форсирование первой без оглядки на вторую ИМХО может вызывать в 
основном академический интерес:)

>
> Такой тест -- позволяет выявить некоторые баги.

-- 
Led

Re: [devel] ACL in branches

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

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

On Mon, Mar 09, 2009 at 03:51:44PM +0200, Led wrote:

L> Первая ("выявление") у нас значительно опережает вторую ("устранение"), 
L> поэтому форсирование первой без оглядки на вторую ИМХО может вызывать в 
L> основном академический интерес:)

Часто это вопрос удобства.

Кроме того тот тест о котором я говорю -- выявляет еще и потенциальных
кандидатов на автоматическую пересборку (с новыми версиями библиотек).

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

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

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

Re: [devel] ACL in branches

[Led]

On Monday 09 March 2009 17:17:23 Денис Смирнов wrote:
> On Mon, Mar 09, 2009 at 03:51:44PM +0200, Led wrote:
>
> L> Первая ("выявление") у нас значительно опережает вторую ("устранение"),
> L> поэтому форсирование первой без оглядки на вторую ИМХО может вызывать в
> L> основном академический интерес:)
>
> Часто это вопрос удобства.
>
> Кроме того тот тест о котором я говорю -- выявляет еще и потенциальных
> кандидатов на автоматическую пересборку (с новыми версиями библиотек).

http://bugzilla.altlinux.org/show_bug.cgi?id=18592

Выявление этого бага как-то помогло? Больше двух лет kernel-headers-common 
успешно тестово пересобирался. Если теперь, не дай Бог, его пересоберут в 
очередной раз и положат в репозитарий - сборка многих пакетов накроется 
медным тазом (без вины их мейнтейнеров):)

-- 
Led

Re: [devel] ACL in branches

[Alexey Tourbin]

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

On Mon, Mar 09, 2009 at 01:32:18AM +0300, Денис Смирнов wrote:
> AT> А бутстрап даёт возможность _незаметно_ засадить трояна.
> AT> http://en.wikipedia.org/wiki/Backdoor_(computing)
> AT> Это накладывает определенные ограничения, в каких комбинациях пакеты
> AT> должны попадать в репозитарий, и какого рода транзакции можно разрешить.
> AT> А именно, сборку пакета нужно рассматривать как функцию исходников и
> AT> содержимого сборочного чрута.  Тогда транзакция должна быть согласована
> AT> по последовательности сборки пакетов: нельзя пропускать пакеты без
> AT> пререквизитов.  На самом деле четкое определение дать не так просто,
> AT> но идея должна быть понятна.
> 
> Я думаю вот что.
> 
> В момент перемещения транзакции в репозиторий при копировании образуется
> некий временный репозиторий. В этом временном репозитории пакеты, которые
> были добавлены/обнавлены транзакцией слияния pocket'а должны быть еще раз
> пересобраны уже в этом репозитории.
> 
> Таким образом мы по крайней мере гарантируем что в момент прохождения
> транзакции эти пакеты при пересборке в этом репозитории дают именно тот
> результат, который отправится в репозиторий.

Это сейчас реализовано автоматически.  Эта логика называется "ребейс".
Задание заново проигрывается на текущем репозитарии (если оно было
отложено).  Если задание проигралось успешно, то происходит (необратимый)
акт согласования задания с репозитарием: задание переводится в режим
"выполнено успшено", а репозитарий обновляется.

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

Что до троянов, то следует изучать статью Кена Томпсона, как внедрить
трояна в компилятор.  Проблема, конечно, не в том, что вообще можно
внедрить куда-то трояна, а в том, что при определенных условиях (а-ля
бутстрап) это можно сделать незаметно.  Спрятать концы в воду.

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

Re: [devel] ACL in branches

[Alexey Tourbin]

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

On Mon, Mar 09, 2009 at 03:47:31AM +0300, Alexey Rusakov wrote:
> В Пнд, 09/03/2009 в 01:32 +0300, Денис Смирнов пишет:
> > Таким образом мы по крайней мере гарантируем что в момент прохождения
> > транзакции эти пакеты при пересборке в этом репозитории дают именно тот
> > результат, который отправится в репозиторий.
> Таким образом мы получаем, что те пакеты, которые мы тестировали в
> покете, и те, которые в итоге попадают в репозиторий, собираются на
> разных пакетных базах. За что боролись?

Вариация результата возможна не только из-за изменения среды сборки,
но и из-за изменения среды рантайма.  В рантайме происходит компонтовка
собственных кусков кода с кусками кода других пакетов.  То есть бывает
компайл-тайм компоновка и рантайм компоновка.  Разговоры о плотном
тестировании вручную как будто исходят из того, что кто-то обязан нам
ничего не менять, если мы что-то протестировали.  Это получается некий
подразумевыемый аналог статической линковки.  При сборке, действительно,
можно при желании получить гарантии на уровне статической компоновки.
Но впоследствии в рантйме гарантий будет всё меньше и меньше.

Поэтому и нет особого смысла налегать на тестирование вручную "здесь и сейчас".

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

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

Re: [devel] ACL in branches

[Mikhail Gusarov]

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


Twas brillig at 22:42:04 10.03.2009 UTC+03 when at@altlinux.ru did gyre and gimble:

 AT> Поэтому и нет особого смысла налегать на тестирование вручную
 AT> "здесь и сейчас".

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

-- 

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

Re: [devel] ACL in branches

[Alexey Tourbin]

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

On Mon, Mar 09, 2009 at 11:09:33AM +0300, Dmitriy M. Maslennikov wrote:
> 9 марта 2009 г. 3:47 пользователь Alexey Rusakov <ktirf@altlinux.org> написал:
> > Таким образом мы получаем, что те пакеты, которые мы тестировали в
> > покете, и те, которые в итоге попадают в репозиторий, собираются на
> > разных пакетных базах. За что боролись?
> Таким образом мы гарантируем, что в репозитории не произошло
> изменений, влияющих на интересующие нас пакеты. Если произошли -
> повторное тестирование.

Изменения могут пройти задним числом, потому что рантайм зависимости
обновляются помимо нашего желания.  Например, если завтра glibc
обновится, то все пакеты можно будет тестировать заново (вручную,
если проверять работоспособность).

Если Вам это не нравится, то Вы добиваетесь чего-то вроде статической
линковки.  Ставьте зависимость Requires: glibc-core = %version-%release
и т.п.  Тогда будет гарантия что протестированое однажды будет работать
всегда.

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

Re: [devel] ACL in branches

[Alexey Tourbin]

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

On Wed, Mar 11, 2009 at 01:44:00AM +0600, Mikhail Gusarov wrote:
>  AT> Поэтому и нет особого смысла налегать на тестирование вручную
>  AT> "здесь и сейчас".
> 
> Вот ты как-то говорил, что я много пожимаю плечами и недоумеваю по
> поводу проекта. Когда я вижу такую глупость (уверенно излагаемую уже
> далеко не первый день) - ничего больше не остаётся, как недоумевать и
> пожимать плечами.

А почему глупость?

В этом споре есть беклог и контекст, которые легко упустить.

Мои оппоненты утверждают, что принципиально важно вручную протестировать
пакет сразу после сборки в girar-builder, но до попадания в репозитарий.

Я оппонирую, что это не принципиально важно: можно протестировать пакет
чуть раньше (после сборки в собственном хешере) или чуть позже (когда
пакет уже пройдёт в сизиф).  А тестирование именно "здесь и сейчас"
дополнительно ничего не дает.

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

Re: [devel] ACL in branches

[Mikhail Gusarov]

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


Twas brillig at 22:47:17 10.03.2009 UTC+03 when at@altlinux.ru did gyre and gimble:

 AT> Например, если завтра glibc обновится, то все пакеты можно будет
 AT> тестировать заново (вручную, если проверять работоспособность).

Это рассуждения в стиле "если каждая строка программы с вероятностью
0.01% содержит ошибку, то программа из 100000 строк работает верно с
вероятностью (1-0.0001)^100000 = ~0.045%".

Почитай уже что-нибудь по теории тестирования, что ли?

-- 

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

Re: [devel] ACL in branches

[Mikhail Gusarov]

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


Twas brillig at 22:52:04 10.03.2009 UTC+03 when at@altlinux.ru did gyre and gimble:

 AT> Мои оппоненты утверждают, что принципиально важно вручную
 AT> протестировать пакет сразу после сборки в girar-builder, но до
 AT> попадания в репозитарий.

 AT> Я оппонирую, что это не принципиально важно: можно протестировать
 AT> пакет чуть раньше (после сборки в собственном хешере) или чуть
 AT> позже (когда пакет уже пройдёт в сизиф).  А тестирование именно
 AT> "здесь и сейчас" дополнительно ничего не дает.

В такой постановке - да. Но как я помню - вопрос ставился немного
по-другому.

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

Такой people-на-стероидах.

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

-- 

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

Re: [devel] ACL in branches

[Dmitriy M. Maslennikov]

10 марта 2009 г. 22:52 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> А почему глупость?
>
> В этом споре есть беклог и контекст, которые легко упустить.
>
> Мои оппоненты утверждают, что принципиально важно вручную протестировать
> пакет сразу после сборки в girar-builder, но до попадания в репозитарий.
>
> Я оппонирую, что это не принципиально важно: можно протестировать пакет
> чуть раньше (после сборки в собственном хешере) или чуть позже (когда
> пакет уже пройдёт в сизиф).  А тестирование именно "здесь и сейчас"
> дополнительно ничего не дает.
Немного не так. Оппоненты говорят, что во-первых тестировать после
попадания в branch уже поздно, так как начнут падать сервера.
Тестированию же мантейнера доверять страшно, он мог:
- вообще не тестировать
- тестировать только ограниченный, важный только ему функционал
- ему я могу не доверять, в принципе, так как он (абстрактный) делает
just for fun, а у меня (абстрактного) сервера в продакшене.
- специально заложить rm -rf / в код пакета.

Тестировать интересные мне пакеты хочу сам.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] ACL in branches

[Alexey Tourbin]

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

On Wed, Mar 11, 2009 at 01:52:22AM +0600, Mikhail Gusarov wrote:
>  AT> Например, если завтра glibc обновится, то все пакеты можно будет
>  AT> тестировать заново (вручную, если проверять работоспособность).
> 
> Это рассуждения в стиле "если каждая строка программы с вероятностью
> 0.01% содержит ошибку, то программа из 100000 строк работает верно с
> вероятностью (1-0.0001)^100000 = ~0.045%".

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

Программы с динамической компоновкой по зависимостям действительно
нельзя вручную протестировать один раз, с тем чтобы дать long-term
гарантию работоспособности.

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

> Почитай уже что-нибудь по теории тестирования, что ли?

Что же мне почитать по теории тестирования?

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

Re: [devel] ACL in branches

[Alexey Tourbin]

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

On Wed, Mar 11, 2009 at 01:56:45AM +0600, Mikhail Gusarov wrote:
> Twas brillig at 22:52:04 10.03.2009 UTC+03 when at@altlinux.ru did gyre and gimble:
> 
>  AT> Мои оппоненты утверждают, что принципиально важно вручную
>  AT> протестировать пакет сразу после сборки в girar-builder, но до
>  AT> попадания в репозитарий.
> 
>  AT> Я оппонирую, что это не принципиально важно: можно протестировать
>  AT> пакет чуть раньше (после сборки в собственном хешере) или чуть
>  AT> позже (когда пакет уже пройдёт в сизиф).  А тестирование именно
>  AT> "здесь и сейчас" дополнительно ничего не дает.
> 
> В такой постановке - да. Но как я помню - вопрос ставился немного
> по-другому.

Вопрос ставился так.  Оппоненты хотят иметь задание, которое собирается,
но автоматически не проходит.  Когда задание собралось, им отправляется
уведомление: "задание собралось но не прошло; тестируйте вручную и
подтверждайте проводить или нет".  Оппоненты тестируют вручную и говорят
"окей, проводите".  На что сборочница отвечает: "извините, пакеты as is
взять нельзя, их пришлось пересобрала, тестируйте ещё раз".  И т.д.

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

> Есть сборки, которые не имеет смысла пропускать в сизиф, потому что
> заранее известно, что они не готовы. Скажем (если взять те пакеты, на
> которых приводились примеры), там отсутствует путь апгрейда
> пользовательских данных с Сизифной версии на новую.  Или автор сборки
> имеет "особое мнение", отличное от мейнтейнера сизифной версии. Или
> что-то ещё.

> Такой people-на-стероидах.

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

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

Можно собирать у себя в хешере и тестировать.  Я так делаю для многих
своих пакетов, в которых нет 'make test'.  А пакеты с 'make test' стал
всё чаще отправлять на сборку без предварительного тестирования в
хост-системе.

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

Re: [devel] ACL in branches

[Mikhail Gusarov]

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


Twas brillig at 23:22:44 10.03.2009 UTC+03 when at@altlinux.ru did gyre and gimble:

 AT> Вопрос ставился так.

[]

К такой постановке вопросов нет.

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

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

 AT> Можно собирать у себя в хешере и тестировать.

Тут тоже про "персональный дедал". Собрал новую версию чего-нибудь
крупного, выложил и предложил потестировать желающим.

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

-- 

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

Re: [devel] ACL in branches

[Mikhail Gusarov]

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


Twas brillig at 23:08:03 10.03.2009 UTC+03 when at@altlinux.ru did gyre and gimble:

 >> Почитай уже что-нибудь по теории тестирования, что ли?

 AT> Что же мне почитать по теории тестирования?

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

-- 

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

Re: [devel] ACL in branches

[Alexey Tourbin]

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

On Tue, Mar 10, 2009 at 10:58:04PM +0300, Dmitriy M. Maslennikov wrote:
> > Я оппонирую, что это не принципиально важно: можно протестировать пакет
> > чуть раньше (после сборки в собственном хешере) или чуть позже (когда
> > пакет уже пройдёт в сизиф).  А тестирование именно "здесь и сейчас"
> > дополнительно ничего не дает.
> Немного не так. Оппоненты говорят, что во-первых тестировать после
> попадания в branch уже поздно, так как начнут падать сервера.
> Тестированию же мантейнера доверять страшно, он мог:
> - вообще не тестировать
> - тестировать только ограниченный, важный только ему функционал

Что Вы хотите от сборочной системы?  Вы хотите от неё очень много и
местами странно.  Сборочная система должна собирать пакеты, которые
её просят собрать.  И отлавливать грубые ошибки (с целью, чтобы можно
было и дальше собирать пакеты, которые её просят собрать).  Если я
правильно понимаю, то раньше такие ошибки вручную отлавливал ldv.

В принципе, можно было бы остановиться на том, что от добра добра
не ищут.

> - ему я могу не доверять, в принципе, так как он (абстрактный) делает
> just for fun, а у меня (абстрактного) сервера в продакшене.
> - специально заложить rm -rf / в код пакета.
> 
> Тестировать интересные мне пакеты хочу сам.

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

Re: [devel] ACL in branches

[Grigory Batalov]

On Tue, Mar 10, 2009 at 10:58:04PM +0300, Dmitriy M. Maslennikov wrote:
> > Я оппонирую, что это не принципиально важно: можно протестировать пакет
> > чуть раньше (после сборки в собственном хешере) или чуть позже (когда
> > пакет уже пройдёт в сизиф).  А тестирование именно "здесь и сейчас"
> > дополнительно ничего не дает.
> Немного не так. Оппоненты говорят, что во-первых тестировать после
> попадания в branch уже поздно, так как начнут падать сервера.
> Тестированию же мантейнера доверять страшно, он мог:
> - вообще не тестировать
> - тестировать только ограниченный, важный только ему функционал
> - ему я могу не доверять, в принципе, так как он (абстрактный) делает
> just for fun, а у меня (абстрактного) сервера в продакшене.
> - специально заложить rm -rf / в код пакета.
> 
> Тестировать интересные мне пакеты хочу сам.

Ну так тестируйте на стенде перед установкой на сервер.
В случае с виртуальными серверами (контейнерами) - а не с физическими -
это особенно просто.

Re: [devel] ACL in branches

[Led]

On Tuesday, 10 March 2009 21:58:04 Dmitriy M. Maslennikov wrote:
> 10 марта 2009 г. 22:52 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> > А почему глупость?
> >
> > В этом споре есть беклог и контекст, которые легко упустить.
> >
> > Мои оппоненты утверждают, что принципиально важно вручную протестировать
> > пакет сразу после сборки в girar-builder, но до попадания в репозитарий.
> >
> > Я оппонирую, что это не принципиально важно: можно протестировать пакет
> > чуть раньше (после сборки в собственном хешере) или чуть позже (когда
> > пакет уже пройдёт в сизиф).  А тестирование именно "здесь и сейчас"
> > дополнительно ничего не дает.
>
> Немного не так. Оппоненты говорят, что во-первых тестировать после
> попадания в branch уже поздно, так как начнут падать сервера.
> Тестированию же мантейнера доверять страшно, он мог:
> - вообще не тестировать
> - тестировать только ограниченный, важный только ему функционал
> - ему я могу не доверять, в принципе, так как он (абстрактный) делает
> just for fun, а у меня (абстрактного) сервера в продакшене.

Если вы обновляете "сервера в продакшене" из branch - вы сами ищете 
приключений на свою... голову. Адекватные админы "сервера в продакшене" 
обновляют только из updates.

> - специально заложить rm -rf / в код пакета.
>
> Тестировать интересные мне пакеты хочу сам.

Естественно. А кто ещё это будет делать за вас?

-- 
Led

Re: [devel] ACL in branches

[Алексей Шенцев]

On Tuesday 10 March 2009 23:27:37 Mikhail Gusarov wrote:
> Twas brillig at 23:08:03 10.03.2009 UTC+03 when at@altlinux.ru did gyre and 
>  AT> Что же мне почитать по теории тестирования?
> Чуть позже дам список литературы, когда кто-нибудь из знакомых QA-шников
> проснётся.
Для начала, Миш, тебе, почитать kennel-sources && sisyphus kernel 
archives ... ;)
P.S.: я конечно понимаю, что ты, Миш, точечный чародей, но всё же ... ;)
-- 
С уважением Шенцев Алексей Владимирович.
E-mail: ashen@nsrz.ru
XMPP: ashen@altlinux.org, AlexShen@jabber.ru
ICQ: 271053845

Re: [devel] ACL in branches

[Mikhail Gusarov]

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


Twas brillig at 09:37:37 11.03.2009 UTC+03 when ashen@nsrz.ru did gyre and gimble:

 >>  AT> Что же мне почитать по теории тестирования?
 >> Чуть позже дам список литературы, когда кто-нибудь из знакомых
 >> QA-шников проснётся.

 АШ> Для начала, Миш, тебе, почитать kennel-sources && sisyphus kernel
 АШ> archives ... ;)

И что же я там *нового* для себя вычитаю?

 АШ> P.S.: я конечно понимаю, что ты, Миш, точечный чародей, но всё же
 АШ> ... ;)

Но всё же аргумент ipse dixit не "прокатит". Приведённый выше пример с
абсурдным вычислением надёжности программы и реакция на него это явно
показывают.

-- 

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

Re: [devel] ACL in branches

[Alexey Rusakov]

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

В Втр, 10/03/2009 в 23:22 +0300, Alexey Tourbin пишет:
> On Wed, Mar 11, 2009 at 01:56:45AM +0600, Mikhail Gusarov wrote:
> > Twas brillig at 22:52:04 10.03.2009 UTC+03 when at@altlinux.ru did gyre and gimble:
> > 
> >  AT> Мои оппоненты утверждают, что принципиально важно вручную
> >  AT> протестировать пакет сразу после сборки в girar-builder, но до
> >  AT> попадания в репозитарий.
> > 
> >  AT> Я оппонирую, что это не принципиально важно: можно протестировать
> >  AT> пакет чуть раньше (после сборки в собственном хешере) или чуть
> >  AT> позже (когда пакет уже пройдёт в сизиф).  А тестирование именно
> >  AT> "здесь и сейчас" дополнительно ничего не дает.
> > 
> > В такой постановке - да. Но как я помню - вопрос ставился немного
> > по-другому.
> 
> Вопрос ставился так.  Оппоненты хотят иметь задание, которое собирается,
> но автоматически не проходит.  Когда задание собралось, им отправляется
> уведомление: "задание собралось но не прошло; тестируйте вручную и
> подтверждайте проводить или нет".  Оппоненты тестируют вручную и говорят
> "окей, проводите".  На что сборочница отвечает: "извините, пакеты as is
> взять нельзя, их пришлось пересобрала, тестируйте ещё раз".  И т.д.
> 
> Я утверждаю, что тестирование вручную по фактору сборочной среды дает
> не очень много.  Потому что ещё есть фактор рантайм-компоновки по
> зависимостям.  Оппоненты хотят контролировать фактор изменения сборочной
> среды и надеются, что это им даст дополнительные гарантии.  Но
> контролировать фактор рантайм-копоновки они не могут даже в принципе.
> 
> > Есть сборки, которые не имеет смысла пропускать в сизиф, потому что
> > заранее известно, что они не готовы. Скажем (если взять те пакеты, на
> > которых приводились примеры), там отсутствует путь апгрейда
> > пользовательских данных с Сизифной версии на новую.  Или автор сборки
> > имеет "особое мнение", отличное от мейнтейнера сизифной версии. Или
> > что-то ещё.
> 
> > Такой people-на-стероидах.
> 
> Это другой контекст спора, который касался "персональных дедалов".
> Впрочем, не исключено, что эти конексты связаны (и ещё более не
> исключено, что мы их смешиваем или путаем).
> 
> > Второй вариант использования - карманы для предварительного тестирования
> > перед бранчами, поскольку допускать регрессии в бранчах более опасно,
> > чем в Сизифе.
> 
> Можно собирать у себя в хешере и тестировать.  Я так делаю для многих
> своих пакетов, в которых нет 'make test'.  А пакеты с 'make test' стал
> всё чаще отправлять на сборку без предварительного тестирования в
> хост-системе.
Сборка "у себя в хешере" исключает возможность групповой работы. То есть
если хочется тестировать не в одиночку, а с привлечением
фэн^Wфан^Wгруппы особых любителей, то опять же выкладывать в people.

Вторая составляющая - это если хочется не тестировать, а собирать
группой. Тот же GNOME 2.26 сейчас выкладывается на people одним
человеком; если выкладывать его туда внесколькером, возникнут проблемы
самого разного плана начиная с прав на /pub/people/gnome. А в сущности
всё сводится к тому, что people не обладает фреймворком для сборки
пакетов, это просто файлохранилище.

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

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

Re: [devel] ACL in branches

[Yuri N. Sedunov]

В Срд, 11/03/2009 в 11:57 +0300, Alexey Rusakov пишет:

> Сборка "у себя в хешере" исключает возможность групповой работы. То есть
> если хочется тестировать не в одиночку, а с привлечением
> фэн^Wфан^Wгруппы особых любителей, то опять же выкладывать в people.
> 
> Вторая составляющая - это если хочется не тестировать, а собирать
> группой. Тот же GNOME 2.26 сейчас выкладывается на people одним
> человеком; если выкладывать его туда внесколькером, возникнут проблемы
> самого разного плана начиная с прав на /pub/people/gnome. А в сущности
> всё сводится к тому, что people не обладает фреймворком для сборки
> пакетов, это просто файлохранилище.

Не надо драматизировать, -- права на /pub/people/gnome есть у команды
@gnome, к которой можно легко присоединиться. Проблемы в другом --
несколькерых желающих принять участие в мифической совместной работе
нема.

-- 
Yuri N. Sedunov

Re: [devel] ACL in branches

[Anton Farygin]

Yuri N. Sedunov пишет:
> В Срд, 11/03/2009 в 11:57 +0300, Alexey Rusakov пишет:
> 
>> Сборка "у себя в хешере" исключает возможность групповой работы. То есть
>> если хочется тестировать не в одиночку, а с привлечением
>> фэн^Wфан^Wгруппы особых любителей, то опять же выкладывать в people.
>>
>> Вторая составляющая - это если хочется не тестировать, а собирать
>> группой. Тот же GNOME 2.26 сейчас выкладывается на people одним
>> человеком; если выкладывать его туда внесколькером, возникнут проблемы
>> самого разного плана начиная с прав на /pub/people/gnome. А в сущности
>> всё сводится к тому, что people не обладает фреймворком для сборки
>> пакетов, это просто файлохранилище.
> 
> Не надо драматизировать, -- права на /pub/people/gnome есть у команды
> @gnome, к которой можно легко присоединиться. Проблемы в другом --
> несколькерых желающих принять участие в мифической совместной работе
> нема.
> 

Добавьте меня, пожалуйста, в группу @gnome

Re: [devel] ACL in branches

[Alexey Rusakov]

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

В Срд, 11/03/2009 в 15:47 +0300, Yuri N. Sedunov пишет:
> Не надо драматизировать, -- права на /pub/people/gnome есть у команды
> @gnome, к которой можно легко присоединиться.
Это отрадно. Правда, полноценного фреймворка для сборки
в /pub/people/gnome всё равно нет, но по крайней мере нет препятствий.

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

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

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

Re: [devel] ACL in branches

[Yuri N. Sedunov]

В Срд, 11/03/2009 в 16:19 +0300, Alexey Rusakov пишет:
> В Срд, 11/03/2009 в 15:47 +0300, Yuri N. Sedunov пишет:
> > Не надо драматизировать, -- права на /pub/people/gnome есть у команды
> > @gnome, к которой можно легко присоединиться.
> Это отрадно. Правда, полноценного фреймворка для сборки
> в /pub/people/gnome всё равно нет, но по крайней мере нет препятствий.

Есть еще /incoming/gnome и bagzilla.altlinux.org -- вполне себе
фреймворк для пары патчей за полгода.

> 
> > Проблемы в другом -- несколькерых желающих принять участие в мифической совместной работе
> > нема.
> Юрий, если вы будете ещё более секретно начинать сборку очередной версии
> GNOME, их будет ещё меньше :) 

В рассылке gnome@ сообщение о репозитарии с новым гномом датируется 30-м
января сего года.

> На мои пусть небольшие, но тоже силы по
> сборке пакетов можно рассчитывать, между прочим. 

Уверен, у Вас другие более важные задачи.

> Патчи на Наутилус я в
> багзиллу кидал, могу собрать с ними пакет.

В nautilus-2.25.93 соответствующий гном-баг исправлен, -- правда, не
смотрел еще как.

-- 
Yuri N. Sedunov

Re: [devel] ACL in branches

[Yuri N. Sedunov]

В Срд, 11/03/2009 в 16:17 +0300, Anton Farygin пишет:
> Yuri N. Sedunov пишет:
> > В Срд, 11/03/2009 в 11:57 +0300, Alexey Rusakov пишет:
<skip>
> > 
> > Не надо драматизировать, -- права на /pub/people/gnome есть у команды
> > @gnome, к которой можно легко присоединиться. Проблемы в другом --
> > несколькерых желающих принять участие в мифической совместной работе
> > нема.
> > 
> 
> Добавьте меня, пожалуйста, в группу @gnome

Антон, меня тут предупредили, что ты опасен, -- для GNOME, в
частности :).  У тебя уже есть исправления? Может для начала через
багзиллу?

-- 
Yuri N. Sedunov

Re: [devel] ACL in branches

[Alexey Rusakov]

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

В Срд, 11/03/2009 в 16:37 +0300, Yuri N. Sedunov пишет:
> В Срд, 11/03/2009 в 16:19 +0300, Alexey Rusakov пишет:
> > В Срд, 11/03/2009 в 15:47 +0300, Yuri N. Sedunov пишет:
> > > Не надо драматизировать, -- права на /pub/people/gnome есть у команды
> > > @gnome, к которой можно легко присоединиться.
> > Это отрадно. Правда, полноценного фреймворка для сборки
> > в /pub/people/gnome всё равно нет, но по крайней мере нет препятствий.
> 
> Есть еще /incoming/gnome и bagzilla.altlinux.org -- вполне себе
> фреймворк для пары патчей за полгода.
> 
> > 
> > > Проблемы в другом -- несколькерых желающих принять участие в мифической совместной работе
> > > нема.
> > Юрий, если вы будете ещё более секретно начинать сборку очередной версии
> > GNOME, их будет ещё меньше :) 
> 
> В рассылке gnome@ сообщение о репозитарии с новым гномом датируется 30-м
> января сего года.
> 
> > На мои пусть небольшие, но тоже силы по
> > сборке пакетов можно рассчитывать, между прочим. 
> 
> Уверен, у Вас другие более важные задачи.
> 
> > Патчи на Наутилус я в
> > багзиллу кидал, могу собрать с ними пакет.
> 
> В nautilus-2.25.93 соответствующий гном-баг исправлен, -- правда, не
> смотрел еще как.
Он там как раз неправильно исправлен, гильотинированием.

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

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

Re: [devel] ACL in branches

[Anton Farygin]

Yuri N. Sedunov пишет:
> В Срд, 11/03/2009 в 16:17 +0300, Anton Farygin пишет:
>> Yuri N. Sedunov пишет:
>>> В Срд, 11/03/2009 в 11:57 +0300, Alexey Rusakov пишет:
> <skip>
>>> Не надо драматизировать, -- права на /pub/people/gnome есть у команды
>>> @gnome, к которой можно легко присоединиться. Проблемы в другом --
>>> несколькерых желающих принять участие в мифической совместной работе
>>> нема.
>>>
>> Добавьте меня, пожалуйста, в группу @gnome
> 
> Антон, меня тут предупредили, что ты опасен, -- для GNOME, в
> частности :).  У тебя уже есть исправления? Может для начала через
> багзиллу?

Ну, тут был недостаток желающих ;)

Исправлений пока нет, но багов вижу много:
- тяжёлый (реально тяжёлый) gnome-default - всё как-то странно и много 
чего пришлось настраивать (Спасибо Ktirf и raorn - помогли).

- уже один раз пришлось прибивать gnome-screensaver.
- два Gnome в gdm - один GNOME, другой "Gnome". Запускаются разные 
оконные менеджеры.

Всё остальное, пока - нравится ;)

Re: [devel] ACL in branches

[Yuri N. Sedunov]

В Срд, 11/03/2009 в 17:11 +0300, Anton Farygin пишет:
> Yuri N. Sedunov пишет:
> > В Срд, 11/03/2009 в 16:17 +0300, Anton Farygin пишет:
> >> Yuri N. Sedunov пишет:
> >>> В Срд, 11/03/2009 в 11:57 +0300, Alexey Rusakov пишет:
> > <skip>
> >>> Не надо драматизировать, -- права на /pub/people/gnome есть у команды
> >>> @gnome, к которой можно легко присоединиться. Проблемы в другом --
> >>> несколькерых желающих принять участие в мифической совместной работе
> >>> нема.
> >>>
> >> Добавьте меня, пожалуйста, в группу @gnome
> > 
> > Антон, меня тут предупредили, что ты опасен, -- для GNOME, в
> > частности :).  У тебя уже есть исправления? Может для начала через
> > багзиллу?
> 
> Ну, тут был недостаток желающих ;)
> 
Желающих у нас полно, реально участвующих почти нет.

> Исправлений пока нет, но багов вижу много:
> - тяжёлый (реально тяжёлый) gnome-default - всё как-то странно и много 
> чего пришлось настраивать (Спасибо Ktirf и raorn - помогли).

Реально много настраивать -- это снести sawfish и поставить
metacity-gnome? Так это raorn тебе и исправлял последствия своей же
инициативы.

> 
> - уже один раз пришлось прибивать gnome-screensaver.

Вот, тебе теперь надо пройти испытание нестабильным гномом
из /pub/people/gnome, заодно и новый g-s-s испытаешь :)

> - два Gnome в gdm - один GNOME, другой "Gnome". Запускаются разные 
> оконные менеджеры.
> 
С sawfish'ем к raorn'у.
-- 
Yuri N. Sedunov

Re: [devel] ACL in branches

[Alexey Rusakov]

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

В Срд, 11/03/2009 в 17:29 +0300, Yuri N. Sedunov пишет:
> > - тяжёлый (реально тяжёлый) gnome-default - всё как-то странно и много 
> > чего пришлось настраивать (Спасибо Ktirf и raorn - помогли).
> 
> Реально много настраивать -- это снести sawfish и поставить
> metacity-gnome? Так это raorn тебе и исправлял последствия своей же
> инициативы.
Сносить sawfish не нужно, нужно только поставить metacity-gnome. Про
metacity-gnome и его соперников я написал #19133.

> > - два Gnome в gdm - один GNOME, другой "Gnome". Запускаются разные 
> > оконные менеджеры.
> > 
> С sawfish'ем к raorn'у.
Не, они оба не относятся к Sawfish, уже посмотрели. Но по-моему, это
всё-таки local misconfiguration, у меня вроде один.

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

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

Re: [devel] ACL in branches

[Alexey Tourbin]

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

On Wed, Mar 11, 2009 at 11:57:03AM +0300, Alexey Rusakov wrote:
> > Можно собирать у себя в хешере и тестировать.  Я так делаю для многих
> > своих пакетов, в которых нет 'make test'.  А пакеты с 'make test' стал
> > всё чаще отправлять на сборку без предварительного тестирования в
> > хост-системе.
> Сборка "у себя в хешере" исключает возможность групповой работы. То есть
> если хочется тестировать не в одиночку, а с привлечением
> фэн^Wфан^Wгруппы особых любителей, то опять же выкладывать в people.

Пожалуй.  То есть "да", некоторый смысл это имеет.
Но есть и возражения.

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

Во-вторых, есть сборочная система и есть смутные чаяния какой-то
идеальной инфраструктуры, которая всем поможет.  У сборочной системы
есть свои резоны делать те или иные вещи.  А смутные предчувствия
сборочная система обслуживать не обязана.  Кто-то хочет чтобы сборочная
система останавливалась и давала протестировать пакеты вручную.  Райдер
хочет чтобы сборочная система давала доступ внутрь чрута хешера.  Ещё
кто-то хочет, чтобы сборочная система собирала пакеты не в бранчи а в
бекпорты или в персональные дедалы или куда-то ещё.  Что должны делать
разработчики сборочной системы?  Идти на поводу нельзя, не принимать к
сведению тоже нельзя.

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

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

> человеком; если выкладывать его туда внесколькером, возникнут проблемы
> самого разного плана начиная с прав на /pub/people/gnome. А в сущности
> всё сводится к тому, что people не обладает фреймворком для сборки
> пакетов, это просто файлохранилище.

Фреймворк -- это сомнительное понятие (на таком уровне).  Я предпочитаю
говорить о модели данных.  Если хочется больше, чем файлохранилище.

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

Re: [devel] ACL in branches

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

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

On Tue, Mar 10, 2009 at 11:50:43PM +0200, Led wrote:

L> Если вы обновляете "сервера в продакшене" из branch - вы сами ищете 
L> приключений на свою... голову. Адекватные админы "сервера в продакшене" 
L> обновляют только из updates.

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

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

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

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

Re: [devel] ACL in branches

[Led]

On Wednesday, 11 March 2009 21:17:17 Денис Смирнов wrote:
> On Tue, Mar 10, 2009 at 11:50:43PM +0200, Led wrote:
>
> L> Если вы обновляете "сервера в продакшене" из branch - вы сами ищете
> L> приключений на свою... голову. Адекватные админы "сервера в продакшене"
> L> обновляют только из updates.
>
> При том насколько "хорошо" поддерживаются updates в ALTLinux если с вашим
> утверждением согласится существенное число членов команды вывод будет
> только один -- ALTLinux не нужен.

А по существу?

-- 
Led

Re: [devel] ACL in branches

[Dmitriy M. Maslennikov]

11 марта 2009 г. 22:24 пользователь Led <ledest@gmail.com> написал:
>> При том насколько "хорошо" поддерживаются updates в ALTLinux если с вашим
>> утверждением согласится существенное число членов команды вывод будет
>> только один -- ALTLinux не нужен.
>
> А по существу?
По существу, он хотел сказать, что либо существуют стабильные
протестированные бранчи, либо ALTLinux никому, кроме его разработчиков
не нужен. Может не так кардинально, но доля истины в этом точно есть.
Вообще очень чувствуется увлечение разработкой красивых инструментов
разработки вместо разработки конечного продукта. Не у всех, конечно,
но у некоторых явно присутствует.

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

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] ACL in branches

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

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

On Tue, Mar 10, 2009 at 10:25:54PM +0300, Алексей Турбин wrote:

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

Необходимость в непрерывности истории в git бутстрап не отменяет. Так что
подобное действие оставит свой след в истории git.

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

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

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

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

Re: [devel] ACL in branches

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

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

On Tue, Mar 10, 2009 at 10:47:17PM +0300, Алексей Турбин wrote:

AT> Изменения могут пройти задним числом, потому что рантайм зависимости
AT> обновляются помимо нашего желания.  Например, если завтра glibc
AT> обновится, то все пакеты можно будет тестировать заново (вручную,
AT> если проверять работоспособность).

Алексей. Ты с собеседниками в этой ветке не понимаете друг-друга из-за
разной позициии восприятия -- со стороны системшика и со стороны
прикладников и админов.

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

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

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

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

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

Re: [devel] ACL in branches

[Led]

On Wednesday, 11 March 2009 21:34:05 Dmitriy M. Maslennikov wrote:
> 11 марта 2009 г. 22:24 пользователь Led <ledest@gmail.com> написал:
> >> При том насколько "хорошо" поддерживаются updates в ALTLinux если с
> >> вашим утверждением согласится существенное число членов команды вывод
> >> будет только один -- ALTLinux не нужен.
> >
> > А по существу?
>
> По существу, он хотел сказать, что либо существуют стабильные
> протестированные бранчи, либо ALTLinux никому, кроме его разработчиков
> не нужен. Может не так кардинально, но доля истины в этом точно есть.
> Вообще очень чувствуется увлечение разработкой красивых инструментов
> разработки вместо разработки конечного продукта. Не у всех, конечно,
> но у некоторых явно присутствует.

ИМХО большинству мейнтейнеров мифический "конечный продукт" мало интересует. 
И? Что будем с ними делать? Когда примете решение - можете начать с меня:)

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

Я не вижу особых проблем с заведением "альтернативных репозитариев". Или 
кто-то категорически запрещает, грозит санкциями?:)

-- 
Led

Re: [devel] ACL in branches

[Anton Farygin]

Денис Смирнов пишет:
> On Tue, Mar 10, 2009 at 10:47:17PM +0300, Алексей Турбин wrote:
> 
> AT> Изменения могут пройти задним числом, потому что рантайм зависимости
> AT> обновляются помимо нашего желания.  Например, если завтра glibc
> AT> обновится, то все пакеты можно будет тестировать заново (вручную,
> AT> если проверять работоспособность).
<skip>
> И подобные ошибки можно (и нужно) ловить ручным тестированием, к
> сожалению. Либо покрывать всю программу целиком юнит-тестами. Выполнить
> второе для всех приложений в Сизифе -- невозможно, остается только ручное
> тестирование.

Для которого изначально и предназначен репозитарий Sisyphus.

Re: [devel] ACL in branches

[Anton Farygin]

Yuri N. Sedunov пишет:
> В Срд, 11/03/2009 в 17:11 +0300, Anton Farygin пишет:
>> Yuri N. Sedunov пишет:
>>> В Срд, 11/03/2009 в 16:17 +0300, Anton Farygin пишет:
>>>> Yuri N. Sedunov пишет:
>>>>> В Срд, 11/03/2009 в 11:57 +0300, Alexey Rusakov пишет:
>>> <skip>
>>>>> Не надо драматизировать, -- права на /pub/people/gnome есть у команды
>>>>> @gnome, к которой можно легко присоединиться. Проблемы в другом --
>>>>> несколькерых желающих принять участие в мифической совместной работе
>>>>> нема.
>>>>>
>>>> Добавьте меня, пожалуйста, в группу @gnome
>>> Антон, меня тут предупредили, что ты опасен, -- для GNOME, в
>>> частности :).  У тебя уже есть исправления? Может для начала через
>>> багзиллу?
>> Ну, тут был недостаток желающих ;)
>>
> Желающих у нас полно, реально участвующих почти нет.
> 
>> Исправлений пока нет, но багов вижу много:
>> - тяжёлый (реально тяжёлый) gnome-default - всё как-то странно и много 
>> чего пришлось настраивать (Спасибо Ktirf и raorn - помогли).
> 
> Реально много настраивать -- это снести sawfish и поставить
> metacity-gnome? Так это raorn тебе и исправлял последствия своей же
> инициативы.
> 
>> - уже один раз пришлось прибивать gnome-screensaver.
> 
> Вот, тебе теперь надо пройти испытание нестабильным гномом
> из /pub/people/gnome, заодно и новый g-s-s испытаешь :)

Лучше расскажи как из git.alt + mainstream это собирается. Просто бинари 
качать накладно (интернет дома дорогой).

> 
>> - два Gnome в gdm - один GNOME, другой "Gnome". Запускаются разные 
>> оконные менеджеры.
>>
> С sawfish'ем к raorn'у.

Понятно.

Re: [devel] ACL in branches

[Anton Farygin]

Alexey Rusakov пишет:
> В Срд, 11/03/2009 в 17:29 +0300, Yuri N. Sedunov пишет:
> Не, они оба не относятся к Sawfish, уже посмотрели. Но по-моему, это
> всё-таки local misconfiguration, у меня вроде один.

Непонятно, откуда они могли бы два взяться... apt-get install 
gnome-default делал при тебе.

Re: [devel] ACL in branches

[Alexey Tourbin]

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

On Wed, Mar 11, 2009 at 10:53:49PM +0300, Денис Смирнов wrote:
> On Tue, Mar 10, 2009 at 10:47:17PM +0300, Алексей Турбин wrote:
> 
> AT> Изменения могут пройти задним числом, потому что рантайм зависимости
> AT> обновляются помимо нашего желания.  Например, если завтра glibc
> AT> обновится, то все пакеты можно будет тестировать заново (вручную,
> AT> если проверять работоспособность).
> 
> Алексей. Ты с собеседниками в этой ветке не понимаете друг-друга из-за
> разной позициии восприятия -- со стороны системшика и со стороны
> прикладников и админов.

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

Но в основе сборочной системы лежат идеи (изложенные в тезисах моего
доклада), которые вряд ли претерпят существенные изменения.
ftp://ftp.altlinux.org/pub/people/at/protva-2008.pdf

А именно, сборочная система работает так:
1) Собирает пакеты, которые её просят собрать.
2) Формирует новый репозитарий (во временном каталоге).
3) Вычисляет характеристики текущего репозитария и нового репозитария.
4) Если характеристики ухудшились, то пакеты отвергаются.
5) Если характеристики не ухудшились, то пакеты проходят (новый временный
репозитарий становится текущим).

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

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

Мне кажется, что эти идеи настолько просты, прозрачны и справедливы, что
лучше что-либо придумать просто нельзя.  Это если мы хотим поддерживать
целостный репозиатрий, а не хранилище файлов с расширением *.rpm.

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

Окей, давайте искать примирения.  Что могут сделать разработчики
сборочной системы, если не решить все проблемы за счет создания
полумифической "инфраструктуры" или "фреймворка"?

Можно сделать следующее:

1) Реализовать manual-режим подтверждения заданий.
Его уже частично реализовал ldv.

2) В самом задании формировать каталог RPMS.hasher, который будет
доступн через напр. git.altlinux.org::tasks/N/hasher/repo/RPMS.hasher.

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

Re: [devel] ACL in branches

[Yuri N. Sedunov]

В Срд, 11/03/2009 в 23:38 +0300, Anton Farygin пишет:
<skip>
> > 
> >> - уже один раз пришлось прибивать gnome-screensaver.
> > 
> > Вот, тебе теперь надо пройти испытание нестабильным гномом
> > из /pub/people/gnome, заодно и новый g-s-s испытаешь :)
> 
> Лучше расскажи как из git.alt + mainstream это собирается. 
Это всё собирается традиционно, по старинке.

> Просто бинари 
> качать накладно (интернет дома дорогой).

Любопытно, сколько ты собираешься сэкономить в мегабайтах не качая
пакеты.
-- 
Yuri N. Sedunov

Re: [devel] ACL in branches

[Anton Farygin]

Yuri N. Sedunov пишет:
> В Срд, 11/03/2009 в 23:38 +0300, Anton Farygin пишет:
> <skip>
>>>> - уже один раз пришлось прибивать gnome-screensaver.
>>> Вот, тебе теперь надо пройти испытание нестабильным гномом
>>> из /pub/people/gnome, заодно и новый g-s-s испытаешь :)
>> Лучше расскажи как из git.alt + mainstream это собирается. 
> Это всё собирается традиционно, по старинке.

Жаль. А есть переспективы интеграции в git ? gnome для своих пакетов 
использует subversion - через git-svn это довольно просто втаскивается в 
git.alt.

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

Это не имеет значения, при цене 2р/мегабайт.

С учётом того, что git я утяну на условно-бесплатном канале, а пакеты 
занимают:

lftp ftp.altlinux.org:/pub/people/gnome/gnome-2.25/i586/RPMS.hasher> du -s .
113779  .

И качать явно придётся не один раз.

Re: [devel] ACL in branches

[Alexey Rusakov]

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

В Чтв, 12/03/2009 в 00:17 +0300, Anton Farygin пишет:
> Yuri N. Sedunov пишет:
> > В Срд, 11/03/2009 в 23:38 +0300, Anton Farygin пишет:
> > <skip>
> >>>> - уже один раз пришлось прибивать gnome-screensaver.
> >>> Вот, тебе теперь надо пройти испытание нестабильным гномом
> >>> из /pub/people/gnome, заодно и новый g-s-s испытаешь :)
> >> Лучше расскажи как из git.alt + mainstream это собирается. 
> > Это всё собирается традиционно, по старинке.
> 
> Жаль. А есть переспективы интеграции в git ? gnome для своих пакетов 
> использует subversion - через git-svn это довольно просто втаскивается в 
> git.alt.
GNOME собирается на git переползать в обозримом будущем. Это не в пользу
и не против, просто информация.

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

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

Re: [devel] ACL in branches

[Yuri N. Sedunov]

В Чтв, 12/03/2009 в 00:17 +0300, Anton Farygin пишет:
> Yuri N. Sedunov пишет:
> > В Срд, 11/03/2009 в 23:38 +0300, Anton Farygin пишет:
> > <skip>
> >>>> - уже один раз пришлось прибивать gnome-screensaver.
> >>> Вот, тебе теперь надо пройти испытание нестабильным гномом
> >>> из /pub/people/gnome, заодно и новый g-s-s испытаешь :)
> >> Лучше расскажи как из git.alt + mainstream это собирается. 
> > Это всё собирается традиционно, по старинке.
> 
> Жаль. А есть переспективы интеграции в git ? 
Личной мотивации у меня нет. 

> gnome для своих пакетов 
> использует subversion 

Для сборки в основном используются тарболы с ftp.gnome.org.

> - через git-svn это довольно просто втаскивается в 
> git.alt.

Подробная (пошаговая) инструкция, с приложенным расчетом времени на
организацию git/gear-репозитория для одного пакета, будет способствовать
началу процесса интеграции.

-- 
Yuri N. Sedunov

Re: [devel] ACL in branches

[Anton Farygin]

Yuri N. Sedunov пишет:
> В Чтв, 12/03/2009 в 00:17 +0300, Anton Farygin пишет:

<skip>

> Подробная (пошаговая) инструкция, с приложенным расчетом времени на
> организацию git/gear-репозитория для одного пакета, будет способствовать
> началу процесса интеграции.

ok. Я попробую это сам сделать на одном из гномовских пакетов. (для 
примера, возьмём libgnome). Я правильно понимаю, что вся история 
разработки libgnome не имеет никакого значения ? т.е. - начинать можно с 
текущего trunk ?

Re: [devel] ACL in branches

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

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

On Wed, Mar 11, 2009 at 09:41:02PM +0300, Алексей Турбин wrote:

AT> Во-первых, сборка в хешере не есть такое уж достижение по сравнению
AT> с публикацией исходников.

Я бы с этим согласился если бы это сказал кто угодно, кроме тебя.
Не ты ли всем твердишь про значимость окружения в котором был собран
пакет? ;)

AT> Желающие могут забирать не собранные пакеты,
AT> а исходники.  (То есть привлекать к тестированию можно на уровне
AT> git-коммитов, а не на уровне выкладывания сборок.)  Может быть, это не
AT> очень удобно.  Ситуация с трафиком за последние несколько лет
AT> изменилась, и теперь уже проще взять собранные пакеты, а не дельту
AT> исходников.

Для многих не-разработчиков дела обстоят именно так. Есть люди которые
готовы тестировать пакеты если я им скажу "натрави apt на вон-тот репо",
но которые как только я скажу слово "git" пошлют меня с моими просьбами о
тестировании далеко, надолго, и скорее всего с использованием других менее
приятных 3-х буквенных слов :)

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

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

AT> У сборочной системы
AT> есть свои резоны делать те или иные вещи.  А смутные предчувствия
AT> сборочная система обслуживать не обязана.  Кто-то хочет чтобы сборочная
AT> система останавливалась и давала протестировать пакеты вручную.  Райдер
AT> хочет чтобы сборочная система давала доступ внутрь чрута хешера.  Ещё
AT> кто-то хочет, чтобы сборочная система собирала пакеты не в бранчи а в
AT> бекпорты или в персональные дедалы или куда-то ещё.  Что должны делать
AT> разработчики сборочной системы?  Идти на поводу нельзя, не принимать к
AT> сведению тоже нельзя.

Думаю разработчикам сборочной системы будет полезно прислушаться к
пожеланиям пользователей по крайней мере, а уж потом решать что и с каким
приоритетом делать :)

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

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

>> человеком; если выкладывать его туда внесколькером, возникнут проблемы
>> самого разного плана начиная с прав на /pub/people/gnome. А в сущности
>> всё сводится к тому, что people не обладает фреймворком для сборки
>> пакетов, это просто файлохранилище.
AT> Фреймворк -- это сомнительное понятие (на таком уровне).  Я предпочитаю
AT> говорить о модели данных.  Если хочется больше, чем файлохранилище.

Модель данных известна -- apt-get'able репо. Это первый этап. А следующий
-- удобный инструментарий для управления этими данными ;)

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

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

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

Re: [devel] ACL in branches

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

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

On Tue, Mar 10, 2009 at 11:22:44PM +0300, Алексей Турбин wrote:

AT> Вопрос ставился так.  Оппоненты хотят иметь задание, которое собирается,
AT> но автоматически не проходит.  Когда задание собралось, им отправляется
AT> уведомление: "задание собралось но не прошло; тестируйте вручную и
AT> подтверждайте проводить или нет".  Оппоненты тестируют вручную и говорят
AT> "окей, проводите".  На что сборочница отвечает: "извините, пакеты as is
AT> взять нельзя, их пришлось пересобрала, тестируйте ещё раз".  И т.д.

Плевать мне на пересборку. Если после пересборки requires/provides пакета
не изменились, то с точки зрения того функционального тестирования о
котором сейчас идет речь -- это означает что пакеты можно пропускать.

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

Его в принципе невозможно контролировать в репозитории. Потому что среда
уже после выкладывания пакетов может измениться, и это неизбежно. Однако
rm -rf / в %pre это отловит.

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

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

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

Re: [devel] ACL in branches

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

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

On Wed, Mar 11, 2009 at 11:15:29PM +0300, Anton Farygin wrote:

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

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

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

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

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

Re: [devel] ACL in branches

[Yuri N. Sedunov]

В Чтв, 12/03/2009 в 07:30 +0300, Anton Farygin пишет:
> Yuri N. Sedunov пишет:
> > В Чтв, 12/03/2009 в 00:17 +0300, Anton Farygin пишет:
> 
> <skip>
> 
> > Подробная (пошаговая) инструкция, с приложенным расчетом времени на
> > организацию git/gear-репозитория для одного пакета, будет способствовать
> > началу процесса интеграции.
> 
> ok. Я попробую это сам сделать на одном из гномовских пакетов. (для 
> примера, возьмём libgnome). Я правильно понимаю, что вся история 
> разработки libgnome не имеет никакого значения ? т.е. - начинать можно с 
> текущего trunk ?

Для libgnome -- да. 

-- 
Yuri N. Sedunov

Re: [devel] ACL in branches

[Dmitriy M. Maslennikov]

11 марта 2009 г. 23:45 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> Окей, давайте искать примирения.  Что могут сделать разработчики
> сборочной системы, если не решить все проблемы за счет создания
> полумифической "инфраструктуры" или "фреймворка"?
>
> Можно сделать следующее:
>
> 1) Реализовать manual-режим подтверждения заданий.
> Его уже частично реализовал ldv.
>
> 2) В самом задании формировать каталог RPMS.hasher, который будет
> доступн через напр. git.altlinux.org::tasks/N/hasher/repo/RPMS.hasher.
Для начала это то, что надо. Еще неплохо было бы, чтобы для бранчей
подтверждение всегда было бы ручным и не быстрее некоторого времени, и
обязательно с ручкой быстрого пропуска у ответственных людей, для
быстрого принятия срочных фиксов.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] ACL in branches

[Anton Farygin]

Денис Смирнов пишет:
> On Wed, Mar 11, 2009 at 11:15:29PM +0300, Anton Farygin wrote:
> 
>>> И подобные ошибки можно (и нужно) ловить ручным тестированием, к
>>> сожалению. Либо покрывать всю программу целиком юнит-тестами. Выполнить
>>> второе для всех приложений в Сизифе -- невозможно, остается только ручное
>>> тестирование.
> AF> Для которого изначально и предназначен репозитарий Sisyphus.
> 
> Увы, есть изменения несовместимые с нормальным использованием Сизифа на
> рабочих системах мантейнеров, без коего тестировать собственно невозможно.

Например ?

Вообще, для несовместимых изменений всегда есть Hold.

Re: [devel] ACL in branches

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

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

On Wed, Mar 11, 2009 at 11:45:35PM +0300, Алексей Турбин wrote:

AT> Мне кажется, что эти идеи настолько просты, прозрачны и справедливы, что
AT> лучше что-либо придумать просто нельзя.  Это если мы хотим поддерживать
AT> целостный репозиатрий, а не хранилище файлов с расширением *.rpm.

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

AT> 1) Реализовать manual-режим подтверждения заданий.
AT> Его уже частично реализовал ldv.
AT> 2) В самом задании формировать каталог RPMS.hasher, который будет
AT> доступн через напр. git.altlinux.org::tasks/N/hasher/repo/RPMS.hasher.

В первом приближении это задачу создания pocket'ов решает.

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

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

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

Re: [devel] ACL in branches

[Mikhail Gusarov]

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


Twas brillig at 13:30:50 12.03.2009 UTC+03 when rider@altlinux.com did gyre and gimble:

 AF> Вообще, для несовместимых изменений всегда есть Hold.

Postfactum, ага. Гыгы.

-- 

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

Re: [devel] ACL in branches

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

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

On Thu, Mar 12, 2009 at 01:30:50PM +0300, Anton Farygin wrote:
>> Увы, есть изменения несовместимые с нормальным использованием Сизифа на
>> рабочих системах мантейнеров, без коего тестировать собственно невозможно.
AF> Например ?
AF> Вообще, для несовместимых изменений всегда есть Hold.

К тому времени бывает уже поздно :(

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

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

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

Re: [devel] ACL in branches

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

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

On Wed, Mar 11, 2009 at 10:08:20PM +0200, Led wrote:

L> ИМХО большинству мейнтейнеров мифический "конечный продукт" мало интересует. 
L> И? Что будем с ними делать? Когда примете решение - можете начать с меня:)

Мне плевать на все _большинства_, _меньшинства_ и прочие абстрактные
группы.

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

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

Весь этот флейм вообще-то на эту тему.

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

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

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

Re: [devel] ACL in branches

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

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

On Wed, Mar 11, 2009 at 09:24:10PM +0200, Led wrote:

> L>> Если вы обновляете "сервера в продакшене" из branch - вы сами ищете
> L>> приключений на свою... голову. Адекватные админы "сервера в продакшене"
> L>> обновляют только из updates.
>> При том насколько "хорошо" поддерживаются updates в ALTLinux если с вашим
>> утверждением согласится существенное число членов команды вывод будет
>> только один -- ALTLinux не нужен.
L> А по существу?

В ALTLinux не существует updates. В их качестве используются бранчи. А то
что назыается updates -- свои функции не исполняет.

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

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

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

Re: [devel] ACL in branches

[Mikhail Gusarov]

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


Twas brillig at 23:08:03 10.03.2009 UTC+03 when at@altlinux.ru did gyre and gimble:

 AT> Что же мне почитать по теории тестирования?

Glenford Myers "The art of software testing" (в особенности главу 6)

Tim Koomen and Martin Pol "Test Process Improvement" (пропуская буллшит
про мотивацию наёмных обезьянок)

Cem Kaner "Testing Computer Software. Second Edition" (главы 2, 3)

-- 

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

Re: [devel] ACL in branches

[Michael Shigorin]

On Tue, Mar 03, 2009 at 08:59:04PM +0300, Alexey Tourbin wrote:
> > > Нет причины, почему бранч должен быть стабильнее Сизифа.
> > Это не так.  На бранчах по факту меньше скорость изменений
> > (это измеримо)
> Ну и как измерять скорость изменений?

Можно попытаться изобрести некие метрики:

0) количество изменившихся пакетов в единицу времени
1) суммарная разница версий (в следующем приближении
   -- взвешенная с коэффициентами хотя бы по важным
   апстримам, e.g. glibc или libstdc++)
2) количество изменившихся soname
3) количество изменившихся строк кода между сборками
...

Подразумевал в нулевом приближении "количество пакетов".

> И чем плохо что идут изменения, если они в то же самое время
> транзакционно "закрывают" все несовместимости?

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

> > и субъективно -- наблюдается несколько иное отношение к
> > заливаемому, по крайней мере не наблюдаю "ну залей и
> > посмотри, это ж сизиф".
> С моей колокольни это как раз демагогия -- рассуждать кто с
> каким отношением куда залил какой пакет.  С моей колокольни
> надо уметь проверять какие условия выполняются а какие не
> выполняются.

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

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

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

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

PS: извиняюсь за оживлённую переписку, м-да.

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

Re: [devel] backports und branches

[Michael Shigorin]

On Fri, Feb 27, 2009 at 11:19:56PM +0300, Aleksey Novodvorsky wrote:
> Звучит неплохо. Можно это изложить в виде маленького проекта полиси?

Боюсь, мне сейчас слабо.

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

> >> > (когда кто-то "застолбил" софтину и бросил) - ACL'и не
> >> > пересматриваются и подвергаются ревизии то тех пор, пока на
> >> > эти "брошенные" пакеты почему-то не обратит кто-то из 2-3-4
> >> > человек (сами-знаете-кто).
> >> Собственно, что мешает договориться о неких правилах смещения
> >> майнтайнера, если он мышей не ловит ?
> >> К примеру, баги с важностью критично и выше, висящие без
> >> движения/починки эн дней приводят к _автоматическому_ nobody@
> >> на пакет, то же лекарство для пакетов непересобирающихся.
> >> Имеющийся в багзилле патч/ссылка на коммит -- обстоятельство
> >> отягчающее.
> >
> > Или так.
> >
> >> Понятно, что следует явно оговорить, по каким признакам баг
> >> может считаться критичным, да завести некую конфликтную
> >> коммисию.
> >
> > Так вот отож.
> >
> > Предлагаю заменить возлагание дополнительной работы на комиссию
> > (в которую не пойду ни разу) возлаганием дополнительной работы
> > на желающих столбить.  Возможно, как-то автоматизировав
> > настройками git.alt (флажок "я столбю").

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

[devel] о (не)нужности backports (was: ALT: Liberte, egalite, fraternite ou la Mort?)

[Michael Shigorin]

On Thu, Feb 26, 2009 at 11:02:20PM +0300, Alexey Tourbin wrote:
> > Тут нужно найти компромисс между двумя разными задачами: -
> > Выложить свои сборку с минимальным объёмом ответственности...
> > Именные репозитории здесь удобны.
> Мне кажется, что такие сборки особо никому не нужны.  Вы
> поймите, rpm пакеты не существуют сами по себе.  Они существуют
> и имеют смысл только тогда, когда их удается состыковать со
> всем остальным, c master репозитарием.

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

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

Слушай, многим людям удобнее попробовать бэкпорт и обломаться
из-за того, что soname уехал (и мож адаптировать эту сборку),
чем благодаря тому, что тебе или ldv@ это "никому не нужно"
-- заниматься полным комплексом работ по бэкпортированию,
даже если это правка release и пересборка.  Или не заниматься.

Перестань ты расписываться за всех, сам же всё понимаешь.

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

[devel] [JT] несрочно (was: ACL in branches)

[Michael Shigorin]

On Sat, Mar 07, 2009 at 03:57:26PM +0300, Денис Смирнов wrote:
> >> Хорошо бы анонс видеть _за некоторое время_ до изменения. А не "все
> >> сломали давайте чинить".
> > Ну а зачем всё сломать а потом давайте всё чинить?
> Спроси это у тех кто так поступает :)

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

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

Ещё хорошо, когда получается выделить на одну критичную задачу
хотя бы одного человека, которого не имеют права трогать ничем
другим -- именно так у нас и получилось сделать ALTSP.

PS: пишу в devel@, хотя месяц прошёл и тема избитая; просто мне
кажется, что это важно, и не хочется, чтоб был повод огорчиться,
что я это знал и не сказал.  Думаю, все причастные к выпуску
дистрибутивов могут подтвердить мои слова.

Или прямым текстом: пишите альтератор два дня в неделю,
обдумывайте ещё два, и один день оставьте на всякий.
Тогда alterator-lilo будет жив, а mithraen@ -- рад.

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

Re: [devel] [JT] несрочно (was: ACL in branches)

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

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

On Sat, Apr 04, 2009 at 11:31:05AM +0300, Michael Shigorin wrote:

MS> Или прямым текстом: пишите альтератор два дня в неделю,
MS> обдумывайте ещё два, и один день оставьте на всякий.
MS> Тогда alterator-lilo будет жив, а mithraen@ -- рад.

Ты предложил подход который решает много больше проблем чем я озвучил :)

Если говорить про разработку -- то я вон два года назад с extreme
programming баловался. Несмотря на то что половину рабочего времени курили
на балконе и обсуждали "а что нам делать дальше и как?" все задачи были
решены быстро и очень достойно по качеству. В гораздо более жестком режиме
работы в одиночку я подобный же проект в несколько раз по срокам сорвал.

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

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

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