[devel] kernel modules templates

[devel] kernel modules templates

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

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

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

Благо есть замечательные опции:

receive.denyDeletes
receive.denyNonFastForwards

которые не позволят этот общий репозиторий случайно сломать.

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

http://mithraen.ru/
----------------------------------------------------------------------------

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

Re: [devel] kernel modules templates

[Evgeny Sinelnikov]

14 марта 2010 г. 21:50 пользователь Денис Смирнов
<mithraen@altlinux.ru> написал:
> Вопрос - а можно все-таки сделать единое хранилище для шаблонов модулей
> ядра, чтобы не искать их по всему git.alt, и не забывать/не терять их?
>

Да, это было бы неплохо. Я вот всё думал, куда мне шаблоны от
virtualbox заливать?

> Благо есть замечательные опции:
>
> receive.denyDeletes
> receive.denyNonFastForwards
>
> которые не позволят этот общий репозиторий случайно сломать.
>

Эти опции, вероятно стоит тоже стоит сделать управляемыми, как repack
уже сделан. Хотя вопрос с общими репозиториями для girar не так прост.
На git.eter, для этого, есть специальный каталог /projects, и
разграничение сделано
 через группы, что требует umask 0002 и sguid на каждый каталог с проектом.

-- 
Sin (Sinelnikov Evgeny)

Re: [devel] kernel modules templates

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

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

On Mon, Mar 15, 2010 at 01:02:27AM +0300, Evgeny Sinelnikov wrote:

ES> Эти опции, вероятно стоит тоже стоит сделать управляемыми, как repack
ES> уже сделан. 

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

ES> Хотя вопрос с общими репозиториями для girar не так прост.
ES> На git.eter, для этого, есть специальный каталог /projects, и
ES> разграничение сделано
ES>  через группы, что требует umask 0002 и sguid на каждый каталог с проектом.

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

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

http://mithraen.ru/
----------------------------------------------------------------------------

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

Re: [devel] kernel modules templates

[Evgeny Sinelnikov]

15 марта 2010 г. 3:39 пользователь Денис Смирнов <mithraen@altlinux.ru> написал:
> On Mon, Mar 15, 2010 at 01:02:27AM +0300, Evgeny Sinelnikov wrote:
>
> ES> Эти опции, вероятно стоит тоже стоит сделать управляемыми, как repack
> ES> уже сделан.
>
> Эти опции просто необходимость для основного хранилища того, что
> используется большим количеством пользователей. Гарантирует  что никто
> случайно всю историю не потрет.
>
> ES> Хотя вопрос с общими репозиториями для girar не так прост.
> ES> На git.eter, для этого, есть специальный каталог /projects, и
> ES> разграничение сделано
> ES>  через группы, что требует umask 0002 и sguid на каждый каталог с проектом.
>
> Это уже слишком для данной задачи :) Хотелось бы решить сначала
> минимальную -- чтобы было единое место хранения темплейтов, ибо
> заколебало.
>

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

Кроме того нужен ведь более удобный поиск вида /project/PROJECT_NAME.
Я, некоторое время назад полагал, что достаточно определить
ответственного, который будет сам объединять результаты общих усилий в
свой git. Тогда можно будет сделать просто ссылку вида:
/project/PROJECT_NAME ->
/people/ОТВЕТСТВЕННЫЙ/packages/PROJECT_NAME_ОТВЕТСТВЕННОГО

Но это налагает на ответственного регулярную работу по проверке и
подтверждению. Для определённого порядка работы (workflow) это
нормально, но, видимо, не для всякого.


-- 
Sin (Sinelnikov Evgeny)

[devel] [JT] Re: kernel modules templates

[Michael Shigorin]

On Mon, Mar 15, 2010 at 11:25:06AM +0300, Evgeny Sinelnikov wrote:
> Кроме того нужен ведь более удобный поиск вида /project/PROJECT_NAME.

/gears?

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

Это несколько другой workflow, и боюсь, для _упаковки_
(а не разработки) он слишком дорогой.  Для _разработки_
того же mkimage-profiles-desktop -- вполне применяется.

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

PS: а с темплейтами модулей да, наблюдается некоторый резон,
в сильно сгущёном виде описанный одним из разработчиков SVN:
http://lib.custis.ru/The_Risks_of_Distributed_Version_Control
Про gitorious помню, никто ж не добрался.

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

Re: [devel] [JT] Re: kernel modules templates

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

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

On Sat, Mar 20, 2010 at 12:05:46PM +0200, Michael Shigorin wrote:

MS> PS: а с темплейтами модулей да, наблюдается некоторый резон,
MS> в сильно сгущёном виде описанный одним из разработчиков SVN:
MS> http://lib.custis.ru/The_Risks_of_Distributed_Version_Control
MS> Про gitorious помню, никто ж не добрался.

После того как ушли от CVS стало собирать модули менее удобно, чем было
тогда. Т.е. технологически круто, а реально -- неудобно и много сложной
ручной работы.

При этом сделать cvs-like git repo (т.е. тот, в который можно заливать
только обовления, и иметь единый репо для всех) тривиально.

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

http://mithraen.ru/
----------------------------------------------------------------------------

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

Re: [devel] [JT] Re: kernel modules templates

[Dmitry V. Levin]

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

On Sat, Mar 20, 2010 at 05:25:39PM +0300, Денис Смирнов wrote:
> On Sat, Mar 20, 2010 at 12:05:46PM +0200, Michael Shigorin wrote:
> 
> MS> PS: а с темплейтами модулей да, наблюдается некоторый резон,
> MS> в сильно сгущёном виде описанный одним из разработчиков SVN:
> MS> http://lib.custis.ru/The_Risks_of_Distributed_Version_Control
> MS> Про gitorious помню, никто ж не добрался.
> 
> После того как ушли от CVS стало собирать модули менее удобно, чем было
> тогда. Т.е. технологически круто, а реально -- неудобно и много сложной
> ручной работы.
> 
> При этом сделать cvs-like git repo (т.е. тот, в который можно заливать
> только обовления, и иметь единый репо для всех) тривиально.

Сделать cvs-like git repo, в который можно заливать, тривиально.
А вот как сделать такой репозиторий, в который было бы нельзя
_не_ запушить _шаблон_?


-- 
ldv

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

Re: [devel] [JT] Re: kernel modules templates

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

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

On Sat, Mar 20, 2010 at 05:28:57PM +0300, Dmitry V. Levin wrote:

DVL> Сделать cvs-like git repo, в который можно заливать, тривиально.
DVL> А вот как сделать такой репозиторий, в который было бы нельзя
DVL> _не_ запушить _шаблон_?

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

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

Кроме того при сборке с созданием тэга (перед релизом) можно автоматически
push'ить соответствующий шаблон.

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

http://mithraen.ru/
----------------------------------------------------------------------------

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

Re: [devel] [JT] Re: kernel modules templates

[Michael Shigorin]

On Sat, Mar 20, 2010 at 09:05:55PM +0300, Денис Смирнов wrote:
> Есть частичное решение -- merge -s ours в скриптах для сборки
> модулей ядра, чтобы шаблон всегда мержился к собираемому ядру.

А что тут даст -s ours?

PS: из, возможно, контрпримеров: хотелось бы, чтоб
в template/fglrx/sisyphus попала _часть_ коммита 
http://git.altlinux.org/people/mike/packages/?p=kernel-modules.git;a=commitdiff;h=b5b2b0ccdb13fdd4b0c7c5f22bd3359b70682f43
-- но с другой стороны, стоит ли предлагать захламлять общий
шаблон правками, которые специфичны для ядра, которое по задаче
собирается только для i586 и заметно отличается по базовой версии
(2.6.27), т.е. набору необходимых патчей к тому же fglrx?

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

Re: [devel] [JT] Re: kernel modules templates

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

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

On Sat, Mar 20, 2010 at 08:27:34PM +0200, Michael Shigorin wrote:

MS> А что тут даст -s ours?

Если ты делаешь -s ours собираемого модуля ядра с template, то история
темплейта "подшивается" к модулю ядра. И достаточно тривиально получить
темплейт, зная только commit из которого произошла сборка.

MS> PS: из, возможно, контрпримеров: хотелось бы, чтоб
MS> в template/fglrx/sisyphus попала _часть_ коммита 
MS> http://git.altlinux.org/people/mike/packages/?p=kernel-modules.git;a=commitdiff;h=b5b2b0ccdb13fdd4b0c7c5f22bd3359b70682f43
MS> -- но с другой стороны, стоит ли предлагать захламлять общий
MS> шаблон правками, которые специфичны для ядра, которое по задаче
MS> собирается только для i586 и заметно отличается по базовой версии
MS> (2.6.27), т.е. набору необходимых патчей к тому же fglrx?

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

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

http://mithraen.ru/
----------------------------------------------------------------------------

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