[devel] Fwd: [opennet] Релиз ALT Linux 4.0.1 Server

[devel] Fwd: [opennet] Релиз ALT Linux 4.0.1 Server

[Michael Shigorin]

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

Есть предложение всё-таки скинуться опытом использования git.alt
и шишками на конференции или в Обнинске, поскольку если сейчас
весь сизиф взять и перенесть в git.alt -- польза от него для
людей вроде mithraen@ образца нескольких лет тому резко упадёт.
Бишь цеховость подскочит.  А этого бы не хотелось.

(понятно, что можно это компенсировать предложенным новым и
лучшим способом работы, вот только он не admin friendly в
текущем виде, да и не newbie developer friendly, а чтоб профи
заинтересовать -- приходится иметь более веские доводы, чем
"ещё один оригинальный репозиторий, преимущества которого
ярче проявляются на протяжении долгих лет использования")

----- Forwarded message -----

Новое сообщение от 'jiin' <!sgau email ru> в форуме 'Разговоры, обсуждение новостей'
Посмотреть: http://www.opennet.ru/openforum/vsluhforumID3/37729.html#19
Тема: Релиз ALT Linux 4.0.1 Server

>>Кстати интересный бажок такой нашёл. zsh нормально не дополняет 
>>по ssh имена хостов. В багзилле запись от 2005 года что исправлено
>>и используется _known_hosts. Так вот по ip оно дополнять не хотело.
>Ммм... да, было когда-то, поправлено, а вот по ip никогда и не 
>пробовал табить. :) 
Зря очень приятно когда кучку делаешь а в dns смысла прописывать нет.
>
>>А в апстриме в _hosts было поправлено по этому поводу в районе 4.3.0 или
4.3.1. И
>>вот только в альтовом zsh нормально не работает zstyle ':completion:*:hosts' use-ip
>>1 . И что самое интересное изучение srpm мало помогло - патчей там не было.
>Пакет родом отсюда: http://git.altlinux.org/people/at/packages/?p=zsh.git;a=summary
>-- см. тж. http://wiki.sisyphus.ru/devel/git 
Вот проблемма кстати. Смысл тогда зеркалить srpm(хотя я этого не делаю)? Опять
таки ссылки на фтп сайт ведут к srpm. А выкачав его я получается не могу
восстановить в оригинальное состояние с кучкой патчей чтоб
поотключать/повключать нужное. Смысл srpm? А так еще надо что-то себе ставить
чтобы с гита качать, долговато получается для простой пересборки с выкидыванием патчика.
>
>>И только изучение http://www.sisyphus.ru/srpm/zsh/patches помогло понять что 
>>есть zsh-4.3.0-alt-ssh-known_hosts.patch - вот такой патч. И убрав его все пошло
>>как по маслу. 
>Спасибо, передам майнтейнеру; можете переоткрыть ту багу с указанием этого факта?
С багзилой не дружу:)Как то эта вещь меня в деприссию вгоняет, а доку прочесть лень.
>
>>Так просто хотя бы на wiki повесить это дело когда что и 
>>как будет перемещаться. 
>wiki -- это архив постфактум, можно и не успеть за сутки заглянуть, 
>а сильно заранее всё спланировать тоже не всегда возможно.  Черкните 
>ldv@ Cc: mike@, что-нить придумаем -- я как тоже держащий зеркало 
>тоже заинтересован в более выделяемом уведомлении, чем devel@. 
Кхм..Зеркалю я вобще-то только для себя:) Поэтому смысла в этом мало, никому
зеркало не доступно всё равно.А так хоть анонс в рассылку. Всё равно ручками
скрипт пускаю когда охота и отслеживаю.

-----------------------------------------------------------
Ответить: http://www.opennet.ru/post/vsluhforumID3/37729/19/

----- End forwarded message -----

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

Re: [devel] srpms -> gear

[Dmitry V. Levin]

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

Hi,

On Mon, Jul 02, 2007 at 10:30:52PM +0300, Michael Shigorin wrote:
> О, народ уже начал наступать на грабли монолитных патчей или 
> неапстримных тарболов родом из git.

Это радует: раз начал наступать, значит начал смотреть.

> Есть предложение всё-таки скинуться опытом использования git.alt
> и шишками на конференции или в Обнинске,

У меня планируется на конференции в Обнинске выступление на тему
srpms -> gear, можно будет там и/или в кулуарах всё это обсудить.

> поскольку если сейчас
> весь сизиф взять и перенесть в git.alt -- польза от него для
> людей вроде mithraen@ образца нескольких лет тому резко упадёт.
> Бишь цеховость подскочит.  А этого бы не хотелось.

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

Конструктивные предложения, как обычно, приветствуются.

[...]
> >>1 . И что самое интересное изучение srpm мало помогло - патчей там не было.
> >Пакет родом отсюда: http://git.altlinux.org/people/at/packages/?p=zsh.git;a=summary
> >-- см. тж. http://wiki.sisyphus.ru/devel/git 
> Вот проблемма кстати. Смысл тогда зеркалить srpm(хотя я этого не делаю)? Опять
> таки ссылки на фтп сайт ведут к srpm. А выкачав его я получается не могу
> восстановить в оригинальное состояние с кучкой патчей чтоб
> поотключать/повключать нужное. Смысл srpm? А так еще надо что-то себе ставить
> чтобы с гита качать, долговато получается для простой пересборки с выкидыванием патчика.

Видимого смысла в srpm-паетах после миграции на gear-репозитории не будет.


-- 
ldv

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

Re: [devel] Fwd: [opennet] Релиз ALT Linux 4.0.1 Server

[Alexey Gladkov]

Michael Shigorin пишет:
> 	Здравствуйте.
> О, народ уже начал наступать на грабли монолитных патчей или 
> неапстримных тарболов родом из git.
> 
> Есть предложение всё-таки скинуться опытом использования git.alt
> и шишками на конференции или в Обнинске, поскольку если сейчас
> весь сизиф взять и перенесть в git.alt -- польза от него для
> людей вроде mithraen@ образца нескольких лет тому резко упадёт.
> Бишь цеховость подскочит.  А этого бы не хотелось.

Предлагаешь от нового инструментария в пользу привычки ?

> 
> (понятно, что можно это компенсировать предложенным новым и
> лучшим способом работы, вот только он не admin friendly в
> текущем виде, да и не newbie developer friendly, а чтоб профи
> заинтересовать -- приходится иметь более веские доводы, чем
> "ещё один оригинальный репозиторий, преимущества которого
> ярче проявляются на протяжении долгих лет использования")

Я буду докладываться по новой билд системе на конференции.

-- 
Rgrds, legion

Re: [devel] srpms -> gear

[Aleksey Novodvorsky]

On 7/3/07, Dmitry V. Levin <ldv@altlinux.org> wrote:
> Hi,
>
> On Mon, Jul 02, 2007 at 10:30:52PM +0300, Michael Shigorin wrote:
> > О, народ уже начал наступать на грабли монолитных патчей или
> > неапстримных тарболов родом из git.
>
> Это радует: раз начал наступать, значит начал смотреть.
>
> > Есть предложение всё-таки скинуться опытом использования git.alt
> > и шишками на конференции или в Обнинске,
>
> У меня планируется на конференции в Обнинске выступление на тему
> srpms -> gear, можно будет там и/или в кулуарах всё это обсудить.

Дмитрий, дедлайн был вчера!!! Ну, хоть завтра, пжста!

Rgrds, Алексей

>
> > поскольку если сейчас
> > весь сизиф взять и перенесть в git.alt -- польза от него для
> > людей вроде mithraen@ образца нескольких лет тому резко упадёт.
> > Бишь цеховость подскочит.  А этого бы не хотелось.
>
> Смотря как переносить.  Как вы можете видеть, я пока ничего не форсирую,
> хочу чтобы как можно больше людей привыкло к относительно новому
> инструментарию.
>
> Конструктивные предложения, как обычно, приветствуются.
>
> [...]
> > >>1 . И что самое интересное изучение srpm мало помогло - патчей там не было.
> > >Пакет родом отсюда: http://git.altlinux.org/people/at/packages/?p=zsh.git;a=summary
> > >-- см. тж. http://wiki.sisyphus.ru/devel/git
> > Вот проблемма кстати. Смысл тогда зеркалить srpm(хотя я этого не делаю)? Опять
> > таки ссылки на фтп сайт ведут к srpm. А выкачав его я получается не могу
> > восстановить в оригинальное состояние с кучкой патчей чтоб
> > поотключать/повключать нужное. Смысл srpm? А так еще надо что-то себе ставить
> > чтобы с гита качать, долговато получается для простой пересборки с выкидыванием патчика.
>
> Видимого смысла в srpm-паетах после миграции на gear-репозитории не будет.
>
>
> --
> ldv
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
>
>

Re: [devel] Fwd: [opennet] Релиз ALT Linux 4.0.1 Server

[Anton Farygin]

Michael Shigorin wrote:
> 	Здравствуйте.
> О, народ уже начал наступать на грабли монолитных патчей или 
> неапстримных тарболов родом из git.
> 
> Есть предложение всё-таки скинуться опытом использования git.alt
> и шишками на конференции или в Обнинске, поскольку если сейчас
> весь сизиф взять и перенесть в git.alt -- польза от него для
> людей вроде mithraen@ образца нескольких лет тому резко упадёт.
> Бишь цеховость подскочит.  А этого бы не хотелось.
> 
> (понятно, что можно это компенсировать предложенным новым и
> лучшим способом работы, вот только он не admin friendly в
> текущем виде, да и не newbie developer friendly, а чтоб профи
> заинтересовать -- приходится иметь более веские доводы, чем
> "ещё один оригинальный репозиторий, преимущества которого
> ярче проявляются на протяжении долгих лет использования")

Лично меня вполне устраивает подход из пакета ImageMagick с 
оригинальными тарболлами + патчами.

> 
> ----- Forwarded message -----
> 
> Новое сообщение от 'jiin' <!sgau email ru> в форуме 'Разговоры, обсуждение новостей'
> Посмотреть: http://www.opennet.ru/openforum/vsluhforumID3/37729.html#19
> Тема: Релиз ALT Linux 4.0.1 Server
> 
>>> Кстати интересный бажок такой нашёл. zsh нормально не дополняет 
>>> по ssh имена хостов. В багзилле запись от 2005 года что исправлено
>>> и используется _known_hosts. Так вот по ip оно дополнять не хотело.
>> Ммм... да, было когда-то, поправлено, а вот по ip никогда и не 
>> пробовал табить. :) 
> Зря очень приятно когда кучку делаешь а в dns смысла прописывать нет.
>>> А в апстриме в _hosts было поправлено по этому поводу в районе 4.3.0 или
> 4.3.1. И
>>> вот только в альтовом zsh нормально не работает zstyle ':completion:*:hosts' use-ip
>>> 1 . И что самое интересное изучение srpm мало помогло - патчей там не было.
>> Пакет родом отсюда: http://git.altlinux.org/people/at/packages/?p=zsh.git;a=summary
>> -- см. тж. http://wiki.sisyphus.ru/devel/git 
> Вот проблемма кстати. Смысл тогда зеркалить srpm(хотя я этого не делаю)? Опять
> таки ссылки на фтп сайт ведут к srpm. А выкачав его я получается не могу
> восстановить в оригинальное состояние с кучкой патчей чтоб
> поотключать/повключать нужное. Смысл srpm? А так еще надо что-то себе ставить
> чтобы с гита качать, долговато получается для простой пересборки с выкидыванием патчика.
>>> И только изучение http://www.sisyphus.ru/srpm/zsh/patches помогло понять что 
>>> есть zsh-4.3.0-alt-ssh-known_hosts.patch - вот такой патч. И убрав его все пошло
>>> как по маслу. 
>> Спасибо, передам майнтейнеру; можете переоткрыть ту багу с указанием этого факта?
> С багзилой не дружу:)Как то эта вещь меня в деприссию вгоняет, а доку прочесть лень.
>>> Так просто хотя бы на wiki повесить это дело когда что и 
>>> как будет перемещаться. 
>> wiki -- это архив постфактум, можно и не успеть за сутки заглянуть, 
>> а сильно заранее всё спланировать тоже не всегда возможно.  Черкните 
>> ldv@ Cc: mike@, что-нить придумаем -- я как тоже держащий зеркало 
>> тоже заинтересован в более выделяемом уведомлении, чем devel@. 
> Кхм..Зеркалю я вобще-то только для себя:) Поэтому смысла в этом мало, никому
> зеркало не доступно всё равно.А так хоть анонс в рассылку. Всё равно ручками
> скрипт пускаю когда охота и отслеживаю.
> 
> -----------------------------------------------------------
> Ответить: http://www.opennet.ru/post/vsluhforumID3/37729/19/
> 
> ----- End forwarded message -----
> 

Re: [devel] srpms -> gear

[Anton Farygin]

Dmitry V. Levin wrote:
> Hi,
> 
> On Mon, Jul 02, 2007 at 10:30:52PM +0300, Michael Shigorin wrote:
> [...]
>>>> 1 . И что самое интересное изучение srpm мало помогло - патчей там не было.
>>> Пакет родом отсюда: http://git.altlinux.org/people/at/packages/?p=zsh.git;a=summary
>>> -- см. тж. http://wiki.sisyphus.ru/devel/git 
>> Вот проблемма кстати. Смысл тогда зеркалить srpm(хотя я этого не делаю)? Опять
>> таки ссылки на фтп сайт ведут к srpm. А выкачав его я получается не могу
>> восстановить в оригинальное состояние с кучкой патчей чтоб
>> поотключать/повключать нужное. Смысл srpm? А так еще надо что-то себе ставить
>> чтобы с гита качать, долговато получается для простой пересборки с выкидыванием патчика.
> 
> Видимого смысла в srpm-паетах после миграции на gear-репозитории не будет.

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

Я бы не стал отказываться от src.rpm - они намного удобнее чем git в 
этом плане.


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

Re: [devel] srpms -> gear

[Dmitry V. Levin]

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

On Tue, Jul 03, 2007 at 12:28:08AM +0400, Aleksey Novodvorsky wrote:
> On 7/3/07, Dmitry V. Levin <ldv@altlinux.org> wrote:
> > On Mon, Jul 02, 2007 at 10:30:52PM +0300, Michael Shigorin wrote:
> > > О, народ уже начал наступать на грабли монолитных патчей или
> > > неапстримных тарболов родом из git.
> >
> > Это радует: раз начал наступать, значит начал смотреть.
> >
> > > Есть предложение всё-таки скинуться опытом использования git.alt
> > > и шишками на конференции или в Обнинске,
> >
> > У меня планируется на конференции в Обнинске выступление на тему
> > srpms -> gear, можно будет там и/или в кулуарах всё это обсудить.
> 
> Дмитрий, дедлайн был вчера!!! Ну, хоть завтра, пжста!

О чём идёт речь?  Для обсуждения ухода с srpms никаких дедлайнов нет.


-- 
ldv

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

Re: [devel] srpms -> gear

[Aleksey Novodvorsky]

On 7/3/07, Dmitry V. Levin <ldv@altlinux.org> wrote:
> On Tue, Jul 03, 2007 at 12:28:08AM +0400, Aleksey Novodvorsky wrote:
> > On 7/3/07, Dmitry V. Levin <ldv@altlinux.org> wrote:
> > > On Mon, Jul 02, 2007 at 10:30:52PM +0300, Michael Shigorin wrote:
> > > > О, народ уже начал наступать на грабли монолитных патчей или
> > > > неапстримных тарболов родом из git.
> > >
> > > Это радует: раз начал наступать, значит начал смотреть.
> > >
> > > > Есть предложение всё-таки скинуться опытом использования git.alt
> > > > и шишками на конференции или в Обнинске,
> > >
> > > У меня планируется на конференции в Обнинске выступление на тему
> > > srpms -> gear, можно будет там и/или в кулуарах всё это обсудить.
> >
> > Дмитрий, дедлайн был вчера!!! Ну, хоть завтра, пжста!
>
> О чём идёт речь?  Для обсуждения ухода с srpms никаких дедлайнов нет.

Я про "планируемое выступление", если только оно не будет
исключительно в кулуарах.

Rgrds, Алексей

Re: [devel] srpms -> gear

[Dmitry V. Levin]

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

On Tue, Jul 03, 2007 at 01:41:16AM +0400, Aleksey Novodvorsky wrote:
> On 7/3/07, Dmitry V. Levin <ldv@altlinux.org> wrote:
> > On Tue, Jul 03, 2007 at 12:28:08AM +0400, Aleksey Novodvorsky wrote:
> > > On 7/3/07, Dmitry V. Levin <ldv@altlinux.org> wrote:
> > > > On Mon, Jul 02, 2007 at 10:30:52PM +0300, Michael Shigorin wrote:
> > > > > О, народ уже начал наступать на грабли монолитных патчей или
> > > > > неапстримных тарболов родом из git.
> > > >
> > > > Это радует: раз начал наступать, значит начал смотреть.
> > > >
> > > > > Есть предложение всё-таки скинуться опытом использования git.alt
> > > > > и шишками на конференции или в Обнинске,
> > > >
> > > > У меня планируется на конференции в Обнинске выступление на тему
> > > > srpms -> gear, можно будет там и/или в кулуарах всё это обсудить.
> > >
> > > Дмитрий, дедлайн был вчера!!! Ну, хоть завтра, пжста!
> >
> > О чём идёт речь?  Для обсуждения ухода с srpms никаких дедлайнов нет.
> 
> Я про "планируемое выступление", если только оно не будет
> исключительно в кулуарах.

Я в курсе ;)


-- 
ldv

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

Re: [devel] srpms -> gear

[Dmitry V. Levin]

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

On Tue, Jul 03, 2007 at 01:11:30AM +0400, Anton Farygin wrote:
> Dmitry V. Levin wrote:
> > On Mon, Jul 02, 2007 at 10:30:52PM +0300, Michael Shigorin wrote:
> > [...]
> >>>> 1 . И что самое интересное изучение srpm мало помогло - патчей там не было.
> >>> Пакет родом отсюда: http://git.altlinux.org/people/at/packages/?p=zsh.git;a=summary
> >>> -- см. тж. http://wiki.sisyphus.ru/devel/git 
> >> Вот проблемма кстати. Смысл тогда зеркалить srpm(хотя я этого не делаю)? Опять
> >> таки ссылки на фтп сайт ведут к srpm. А выкачав его я получается не могу
> >> восстановить в оригинальное состояние с кучкой патчей чтоб
> >> поотключать/повключать нужное. Смысл srpm? А так еще надо что-то себе ставить
> >> чтобы с гита качать, долговато получается для простой пересборки с выкидыванием патчика.
> > 
> > Видимого смысла в srpm-паетах после миграции на gear-репозитории не будет.
> 
> за исключением того, что у gear-репозитария слишком большой overhead в 
> виде истории за всё время использования.
> 
> Я бы не стал отказываться от src.rpm - они намного удобнее чем git в 
> этом плане.

src.rpm - это фактически snapshot, результат применения gear к
определённому коммиту.  Как вариант, можно придумать не сильно
обременяющий сервер способ выдавать пригодные для сборки hasher'ом
tarball'ы прямо из gear-репозитория.

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

Что-то слабо в это верится.


-- 
ldv

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

Re: [devel] srpms -> gear

[Alexey Gladkov]

Dmitry V. Levin пишет:
> src.rpm - это фактически snapshot, результат применения gear к
> определённому коммиту.  Как вариант, можно придумать не сильно
> обременяющий сервер способ выдавать пригодные для сборки hasher'ом
> tarball'ы прямо из gear-репозитория.

git-archive --format=tar ?

-- 
Rgrds, legion

Re: [devel] srpms -> gear

[Dmitry V. Levin]

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

On Tue, Jul 03, 2007 at 02:00:37AM +0400, Alexey Gladkov wrote:
> Dmitry V. Levin пишет:
> > src.rpm - это фактически snapshot, результат применения gear к
> > определённому коммиту.  Как вариант, можно придумать не сильно
> > обременяющий сервер способ выдавать пригодные для сборки hasher'ом
> > tarball'ы прямо из gear-репозитория.
> 
> git-archive --format=tar ?

Это gitweb умеет уже сейчас, но для сборки такого tarball'а недостаточно,
нужен результат работы gear.


-- 
ldv

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

Re: [devel] srpms -> gear

[Alexey Gladkov]

Dmitry V. Levin пишет:
> Это gitweb умеет уже сейчас, но для сборки такого tarball'а недостаточно,
> нужен результат работы gear.

Сделать gear-archive который делает tarball из gear репозитория ? :)

-- 
Rgrds, legion

Re: [devel] srpms -> gear

[Dmitry V. Levin]

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

On Tue, Jul 03, 2007 at 02:18:44AM +0400, Alexey Gladkov wrote:
> Dmitry V. Levin пишет:
> > Это gitweb умеет уже сейчас, но для сборки такого tarball'а недостаточно,
> > нужен результат работы gear.
> 
> Сделать gear-archive который делает tarball из gear репозитория ? :)

ln -s gear gear-archive ;)


-- 
ldv

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

Re: [devel] Fwd: [opennet] Релиз ALT Linux 4.0.1 Server

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

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

On Mon, Jul 02, 2007 at 10:30:52PM +0300, Michael Shigorin wrote:

MS> Есть предложение всё-таки скинуться опытом использования git.alt
MS> и шишками на конференции или в Обнинске, поскольку если сейчас
MS> весь сизиф взять и перенесть в git.alt -- польза от него для
MS> людей вроде mithraen@ образца нескольких лет тому резко упадёт.
MS> Бишь цеховость подскочит.  А этого бы не хотелось.

Вспоминая себя много лет тому назад -- ой сомневаюсь что я был бы тогда
способен таскать патчи к себе из ALT, если бы они лежали в git, и не было
бы чуть ли не на главной странице altlinux.ru HOWTO "как таскать у нас
патчи". Стянуть патчи из SRPM может даже полный идиот, если он способен
зайти mc в rpm-файлик и скопировать оттуда патч.

git ещё ближайшие годы останется продуктом "для хакеров", а "админ
обыкновенный" считающий что кроме Gentoo/Slackware дистрибутивов нет
вообще, или наоборот что RHEL рулез а остальное детские поделки, остается
за бортом.

Я конечно понимаю что ламеры нам не нужны, но все-таки 7 лет назад я был
сам классическим случаем именно такого ламера. А заинтересовался ALT я
тогда, когда с подачи Миши увидел что многие патчи, которые мне лично
нужны, я могу успешно таскать из ALT. А уж потом подумал-подумал, и понял
что нафига мне собирать каждый раз из исходников, когда в ALT уже
"случайно" оказалось многое сделано или так как я хочу, или лучше чем я
хочу. Соответственно этот факт + community оказались факторами, которых у
конкурентов не было и фактически вынудили меня сделать выбор в пользу ALT,
так как я мог однозначно _убедиться_ в преимуществах.

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

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

http://freesource.info
----------------------------------------------------------------------------
Пишите программы во сне и на ЯВУ.

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

Re: [devel] srpms -> gear

[Anton Farygin]

Dmitry V. Levin wrote:
> On Tue, Jul 03, 2007 at 02:00:37AM +0400, Alexey Gladkov wrote:
>> Dmitry V. Levin пишет:
>>> src.rpm - это фактически snapshot, результат применения gear к
>>> определённому коммиту.  Как вариант, можно придумать не сильно
>>> обременяющий сервер способ выдавать пригодные для сборки hasher'ом
>>> tarball'ы прямо из gear-репозитория.
>> git-archive --format=tar ?
> 
> Это gitweb умеет уже сейчас, но для сборки такого tarball'а недостаточно,
> нужен результат работы gear.

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

Re: [devel] srpms -> gear

[Michael Shigorin]

On Tue, Jul 03, 2007 at 12:18:27AM +0400, Dmitry V. Levin wrote:
> Смотря как переносить.  Как вы можете видеть, я пока ничего не
> форсирую, хочу чтобы как можно больше людей привыкло к
> относительно новому инструментарию.

У меня пока привыкание остановилось на подходе к apache и xmms
(2 solo: помню, но ещё всё так же не смотрел -- видимо, уже на
кофнференции).  Поскольку патчи из разных мест, которые
поддерживаю не я, пока возможней поддерживать со старым добрым
src.rpm, чем в гите.  Проблема в том, что эти два апстрима, 
мягко говоря, консервативные и продавить их туда уже не особо
реально.

> Видимого смысла в srpm-паетах после миграции на
> gear-репозитории не будет.

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

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

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

PS: это не к тому, что всё плохо, а скорее о том, что стоит
иметь в виду (по моему мнению) :)

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

[devel] gear vs patches

[Michael Shigorin]

On Tue, Jul 03, 2007 at 01:09:03AM +0400, Anton Farygin wrote:
> > О, народ уже начал наступать на грабли монолитных патчей или 
> > неапстримных тарболов родом из git.
> Лично меня вполне устраивает подход из пакета ImageMagick с 
> оригинальными тарболлами + патчами.

Ммм... как вариант, а это собирается gear? (хотя 80% вкусности
git по работе с бранчами улетает -- с другой стороны, пока никто
не описал внятной success story по их использованию, а по уже 
пролопаченному репозиторию пойди пойми, как он был получен)

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

Re: [devel] srpms -> gear

[Dmitry V. Levin]

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

On Tue, Jul 03, 2007 at 12:23:29PM +0300, Michael Shigorin wrote:
> On Tue, Jul 03, 2007 at 12:18:27AM +0400, Dmitry V. Levin wrote:
> > Смотря как переносить.  Как вы можете видеть, я пока ничего не
> > форсирую, хочу чтобы как можно больше людей привыкло к
> > относительно новому инструментарию.
> 
> У меня пока привыкание остановилось на подходе к apache и xmms
> (2 solo: помню, но ещё всё так же не смотрел -- видимо, уже на
> кофнференции).  Поскольку патчи из разных мест, которые
> поддерживаю не я, пока возможней поддерживать со старым добрым
> src.rpm, чем в гите.  Проблема в том, что эти два апстрима, 
> мягко говоря, консервативные и продавить их туда уже не особо
> реально.

gear-репозиторий, который получается на выходе gear-srpmimport,
ни чуть не сложнее srpm-пакета, верно?

> > Видимого смысла в srpm-паетах после миграции на
> > gear-репозитории не будет.
> 
> Было бы всё-таки хорошо иметь какой-то простой вариант понять,
> чем отличается пакет от upstream tarball.  Причём не глазами
> разработчика (им проще), а скорее глазами опытного админа.

gitweb?

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

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

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

Зачем человеку может срочно понадобится список всех моих пакетов?
Я сам на него стараюсь не смотреть. :)

P.S. Почему gitweb на этой операции так сильно тормозит?

> Бишь даже с имеющимися
> концептуально крутыми инструментами есть досадные практические 
> проблемы вроде отсутствия кэширования дорогих по времени
> получения результатов в gitweb.

todo++; чем лучше кэшировать?


-- 
ldv

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

Re: [devel] gear vs patches

[Dmitry V. Levin]

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

On Tue, Jul 03, 2007 at 12:28:35PM +0300, Michael Shigorin wrote:
> On Tue, Jul 03, 2007 at 01:09:03AM +0400, Anton Farygin wrote:
> > > О, народ уже начал наступать на грабли монолитных патчей или 
> > > неапстримных тарболов родом из git.
> > Лично меня вполне устраивает подход из пакета ImageMagick с 
> > оригинальными тарболлами + патчами.
> 
> Ммм... как вариант, а это собирается gear?

Да, конечно, так работает "gear-srpmimport --no-unpack",
но я настоятельно рекомендую хранить upstream'ные tar-архивы
в распакованном виде.


-- 
ldv

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

Re: [devel] srpms -> gear

[Led]

В сообщении от Tuesday 03 July 2007 12:28:36 Dmitry V. Levin написал(а):
> On Tue, Jul 03, 2007 at 12:23:29PM +0300, Michael Shigorin wrote:
> > On Tue, Jul 03, 2007 at 12:18:27AM +0400, Dmitry V. Levin wrote:
> > > Смотря как переносить.  Как вы можете видеть, я пока ничего не
> > > форсирую, хочу чтобы как можно больше людей привыкло к
> > > относительно новому инструментарию.
> >
> > У меня пока привыкание остановилось на подходе к apache и xmms
> > (2 solo: помню, но ещё всё так же не смотрел -- видимо, уже на
> > кофнференции).  Поскольку патчи из разных мест, которые
> > поддерживаю не я, пока возможней поддерживать со старым добрым
> > src.rpm, чем в гите.  Проблема в том, что эти два апстрима,
> > мягко говоря, консервативные и продавить их туда уже не особо
> > реально.
>
> gear-репозиторий, который получается на выходе gear-srpmimport,
> ни чуть не сложнее srpm-пакета, верно?
>
> > > Видимого смысла в srpm-паетах после миграции на
> > > gear-репозитории не будет.
> >
> > Было бы всё-таки хорошо иметь какой-то простой вариант понять,
> > чем отличается пакет от upstream tarball.  Причём не глазами
> > разработчика (им проще), а скорее глазами опытного админа.
>
> gitweb?
>
> > Повторюсь, если мы собираемся заниматься серверами и иметь
> > толковые инструменты их администрирования -- следует привлекать
> > опытных админов, поскольку "толк" в инструментах -- это как раз
> > замороженный в бэкендах опыт администрирования, как вот и толк
> > в пакетах -- замороженный в спеках опыт сборки.
>
> Среди нас есть опытные админы, не являющиеся по совместительству
> разработчиками?  Если нет, то как ты предлагаешь моделировать их нужды?

Формально - всё верно. Но почему-то всё больше кажется, что всё идёт к тому, 
что "исходники - только по требованию" и формально доступ "по требованию" к 
ним будет... теоретически...

>
> > Сейчас как минимум то, что твой репозиторий для получения списка
> > пакетов обрабатывается в среднем ближе к минуте -- тоже не
> > помогает знакомиться с наработками.
>
> Зачем человеку может срочно понадобится список всех моих пакетов?
> Я сам на него стараюсь не смотреть. :)
>
> P.S. Почему gitweb на этой операции так сильно тормозит?
>
> > Бишь даже с имеющимися
> > концептуально крутыми инструментами есть досадные практические
> > проблемы вроде отсутствия кэширования дорогих по времени
> > получения результатов в gitweb.
>
> todo++; чем лучше кэшировать?


-- 
Led

Re: [devel] srpms -> gear

[Aleksey Novodvorsky]

On 7/3/07, Led <ledest@gmail.com> wrote:
> В сообщении от Tuesday 03 July 2007 12:28:36 Dmitry V. Levin написал(а):
> > On Tue, Jul 03, 2007 at 12:23:29PM +0300, Michael Shigorin wrote:
> > > On Tue, Jul 03, 2007 at 12:18:27AM +0400, Dmitry V. Levin wrote:
> > > > Смотря как переносить.  Как вы можете видеть, я пока ничего не
> > > > форсирую, хочу чтобы как можно больше людей привыкло к
> > > > относительно новому инструментарию.
> > >
> > > У меня пока привыкание остановилось на подходе к apache и xmms
> > > (2 solo: помню, но ещё всё так же не смотрел -- видимо, уже на
> > > кофнференции).  Поскольку патчи из разных мест, которые
> > > поддерживаю не я, пока возможней поддерживать со старым добрым
> > > src.rpm, чем в гите.  Проблема в том, что эти два апстрима,
> > > мягко говоря, консервативные и продавить их туда уже не особо
> > > реально.
> >
> > gear-репозиторий, который получается на выходе gear-srpmimport,
> > ни чуть не сложнее srpm-пакета, верно?
> >
> > > > Видимого смысла в srpm-паетах после миграции на
> > > > gear-репозитории не будет.
> > >
> > > Было бы всё-таки хорошо иметь какой-то простой вариант понять,
> > > чем отличается пакет от upstream tarball.  Причём не глазами
> > > разработчика (им проще), а скорее глазами опытного админа.
> >
> > gitweb?
> >
> > > Повторюсь, если мы собираемся заниматься серверами и иметь
> > > толковые инструменты их администрирования -- следует привлекать
> > > опытных админов, поскольку "толк" в инструментах -- это как раз
> > > замороженный в бэкендах опыт администрирования, как вот и толк
> > > в пакетах -- замороженный в спеках опыт сборки.
> >
> > Среди нас есть опытные админы, не являющиеся по совместительству
> > разработчиками?  Если нет, то как ты предлагаешь моделировать их нужды?
>
> Формально - всё верно. Но почему-то всё больше кажется, что всё идёт к тому,
> что "исходники - только по требованию" и формально доступ "по требованию" к
> ним будет... теоретически...

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

Rgrds, Алексей

>
> >
> > > Сейчас как минимум то, что твой репозиторий для получения списка
> > > пакетов обрабатывается в среднем ближе к минуте -- тоже не
> > > помогает знакомиться с наработками.
> >
> > Зачем человеку может срочно понадобится список всех моих пакетов?
> > Я сам на него стараюсь не смотреть. :)
> >
> > P.S. Почему gitweb на этой операции так сильно тормозит?
> >
> > > Бишь даже с имеющимися
> > > концептуально крутыми инструментами есть досадные практические
> > > проблемы вроде отсутствия кэширования дорогих по времени
> > > получения результатов в gitweb.
> >
> > todo++; чем лучше кэшировать?
>
>
> --
> Led
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] srpms -> gear

[Dmitry V. Levin]

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

On Tue, Jul 03, 2007 at 02:02:34PM +0400, Aleksey Novodvorsky wrote:
[...]
> Давайте отделять мух от котлет. Здесь нет никого, заинтересованного в
> сокрытии исходников. Наоборот.  Но форма предоставлени исходников
> может меняться. Важно, чтобы она была удобной, а не такой же, как
> всегда.

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


-- 
ldv

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

Re: [devel] srpms -> gear

[Aleksey Novodvorsky]

On 7/3/07, Dmitry V. Levin <ldv@altlinux.org> wrote:
> On Tue, Jul 03, 2007 at 02:02:34PM +0400, Aleksey Novodvorsky wrote:
> [...]
> > Давайте отделять мух от котлет. Здесь нет никого, заинтересованного в
> > сокрытии исходников. Наоборот.  Но форма предоставлени исходников
> > может меняться. Важно, чтобы она была удобной, а не такой же, как
> > всегда.
>
> Собственно говоря, вопрос в том, как, распространяя исходный код в форме,
> наиболее удобной разработчикам, минимизировать неудобства для всех
> остальных.  Ибо неудобства из-за любого изменения формы неизбежны.

В первую очередь нужна хорошая и понятная документация с разъяснением
преимуществ git. Она должна не просто лежать в сторонке, а попадаться
на глаза.

Rgrds, Алексей

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

Re: [devel] srpms -> gear

[Led]

В сообщении от Tuesday 03 July 2007 13:02:34 Aleksey Novodvorsky написал(а):
> On 7/3/07, Led <ledest@gmail.com> wrote:
> > В сообщении от Tuesday 03 July 2007 12:28:36 Dmitry V. Levin написал(а):
> > > On Tue, Jul 03, 2007 at 12:23:29PM +0300, Michael Shigorin wrote:
> > > > On Tue, Jul 03, 2007 at 12:18:27AM +0400, Dmitry V. Levin wrote:
> > > > > Смотря как переносить.  Как вы можете видеть, я пока ничего не
> > > > > форсирую, хочу чтобы как можно больше людей привыкло к
> > > > > относительно новому инструментарию.
> > > >
> > > > У меня пока привыкание остановилось на подходе к apache и xmms
> > > > (2 solo: помню, но ещё всё так же не смотрел -- видимо, уже на
> > > > кофнференции).  Поскольку патчи из разных мест, которые
> > > > поддерживаю не я, пока возможней поддерживать со старым добрым
> > > > src.rpm, чем в гите.  Проблема в том, что эти два апстрима,
> > > > мягко говоря, консервативные и продавить их туда уже не особо
> > > > реально.
> > >
> > > gear-репозиторий, который получается на выходе gear-srpmimport,
> > > ни чуть не сложнее srpm-пакета, верно?
> > >
> > > > > Видимого смысла в srpm-паетах после миграции на
> > > > > gear-репозитории не будет.
> > > >
> > > > Было бы всё-таки хорошо иметь какой-то простой вариант понять,
> > > > чем отличается пакет от upstream tarball.  Причём не глазами
> > > > разработчика (им проще), а скорее глазами опытного админа.
> > >
> > > gitweb?
> > >
> > > > Повторюсь, если мы собираемся заниматься серверами и иметь
> > > > толковые инструменты их администрирования -- следует привлекать
> > > > опытных админов, поскольку "толк" в инструментах -- это как раз
> > > > замороженный в бэкендах опыт администрирования, как вот и толк
> > > > в пакетах -- замороженный в спеках опыт сборки.
> > >
> > > Среди нас есть опытные админы, не являющиеся по совместительству
> > > разработчиками?  Если нет, то как ты предлагаешь моделировать их нужды?
> >
> > Формально - всё верно. Но почему-то всё больше кажется, что всё идёт к
> > тому, что "исходники - только по требованию" и формально доступ "по
> > требованию" к ним будет... теоретически...
>
> Давайте отделять мух от котлет.

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

> Здесь нет никого, заинтересованного в 
> сокрытии исходников. Наоборот.  Но форма предоставлени исходников
> может меняться. Важно, чтобы она была удобной, а не такой же, как
> всегда.
>
> Rgrds, Алексей
>
> > > > Сейчас как минимум то, что твой репозиторий для получения списка
> > > > пакетов обрабатывается в среднем ближе к минуте -- тоже не
> > > > помогает знакомиться с наработками.
> > >
> > > Зачем человеку может срочно понадобится список всех моих пакетов?
> > > Я сам на него стараюсь не смотреть. :)
> > >
> > > P.S. Почему gitweb на этой операции так сильно тормозит?
> > >
> > > > Бишь даже с имеющимися
> > > > концептуально крутыми инструментами есть досадные практические
> > > > проблемы вроде отсутствия кэширования дорогих по времени
> > > > получения результатов в gitweb.
> > >
> > > todo++; чем лучше кэшировать?

-- 
Led

Re: [devel] srpms -> gear

[Dmitry V. Levin]

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

On Tue, Jul 03, 2007 at 01:26:10PM +0300, Led wrote:
> В сообщении от Tuesday 03 July 2007 13:02:34 Aleksey Novodvorsky написал(а):
[...]
> > Давайте отделять мух от котлет.
> 
> я пока не вижу удобного способа "отделить котлеты от мух" в git-репозитариях, 
> а именно - получить тарболл и патчи к пакету из репозитария.

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

Из какого именно репозитория вы не смогли получить тарболл и/или патчи?


-- 
ldv

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

Re: [devel] srpms -> gear

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

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

On Tue, Jul 03, 2007 at 12:23:29PM +0300, Michael Shigorin wrote:

MS> У меня пока привыкание остановилось на подходе к apache и xmms
MS> (2 solo: помню, но ещё всё так же не смотрел -- видимо, уже на
MS> кофнференции).  Поскольку патчи из разных мест, которые
MS> поддерживаю не я, пока возможней поддерживать со старым добрым
MS> src.rpm, чем в гите.  Проблема в том, что эти два апстрима, 
MS> мягко говоря, консервативные и продавить их туда уже не особо
MS> реально.

Как я уже не раз говорил -- тебе это только кажется. Если ты действительно
_хочешь_ перенести в git, то просто натрави на эти пакет gear-srpmimport.
И с получившимся результатом работай так, как будто ты работаешь без
всякого git.

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

Глянь на мой репозиторий с ppp. Там та же самая ситуация.

>> Видимого смысла в srpm-паетах после миграции на
>> gear-репозитории не будет.
MS> Было бы всё-таки хорошо иметь какой-то простой вариант понять,
MS> чем отличается пакет от upstream tarball.  Причём не глазами
MS> разработчика (им проще), а скорее глазами опытного админа.

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

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

http://freesource.info
----------------------------------------------------------------------------
У меня не воспроизводится, но придется воспроизводить.
		-- at in devel@

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

Re: [devel] srpms -> gear

[Led]

В сообщении от Tuesday 03 July 2007 13:40:55 Dmitry V. Levin написал(а):
> On Tue, Jul 03, 2007 at 01:26:10PM +0300, Led wrote:
> > В сообщении от Tuesday 03 July 2007 13:02:34 Aleksey Novodvorsky
> > написал(а):
>
> [...]
>
> > > Давайте отделять мух от котлет.
> >
> > я пока не вижу удобного способа "отделить котлеты от мух" в
> > git-репозитариях, а именно - получить тарболл и патчи к пакету из
> > репозитария.
>
> Разные gear-репозитории устроены по-разному, поскольку практически ничего
> не мешает мантейнерам организовать свои репозитории так как им удобно.
>
> Из какого именно репозитория вы не смогли получить тарболл и/или патчи?

Я не говорил, что "не смог". Я говорил: "не вижу УДОБНОГО способа" (и далее по 
тексту).

Из каких репозитариев - не буду говорить, потому как могу ошибиться и 
наговорить на кого-то "напраслину":). Я давно уже зарёкся "выковыривать" 
что-либо из чьего-то git-репозитария: лично мне на практике проще взять 
оригинальный tarball от разработчика, или даже за-checkout'ить CVS/SVN и 
заново пропатчить. Хотя, возможно, я просто туплю... а, возможно, потому, 
что "Разные gear-репозитории устроены ПО-РАЗНОМУ, поскольку практически 
НИЧЕГО НЕ МЕШАЕТ не мешает мантейнерам организовать свои репозитории так как 
ИМ удобно".

-- 
Led

Re: [devel] srpms -> gear

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

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

On Tue, Jul 03, 2007 at 01:26:10PM +0300, Led wrote:

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

Проведу для всех желающих курс лекций в виде чтения вслух с выражением man
git-diff. Для членов team скидка.

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

Кроме того хочу напомнить что предыдущее обвинение в "сокрытии исходников"
это явная подмена понятий. Исходники того что лежит в Сизифе открыты,
могут быть неочевидны diff'ы между ними и оригиналом. Некоторые пакеты уже
тянут скорее на форк, чем на "пакет плюс пара патчей". Естественно
мантейнер заинтересован в прохождении патчей в апстрим, но иногда это
невозможно по различным принципиальным проблемам -- как то нарушение
патентов на алгоритмы (на кои мы, как живущие в нормальной стране а не США
может внимания не обращать), более жесткая политика безопасности, и т.д.

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

http://freesource.info
----------------------------------------------------------------------------
Чтобы найти библиотеку, надо знать, где ее искать.
		-- wrar in community@

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

Re: [devel] srpms -> gear

[Dmitry V. Levin]

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

On Tue, Jul 03, 2007 at 02:00:08PM +0300, Led wrote:
> В сообщении от Tuesday 03 July 2007 13:40:55 Dmitry V. Levin написал(а):
[...]
> > Из какого именно репозитория вы не смогли получить тарболл и/или патчи?
> 
> Я не говорил, что "не смог". Я говорил: "не вижу УДОБНОГО способа" (и далее по 
> тексту).

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

> Из каких репозитариев - не буду говорить, потому как могу ошибиться и 
> наговорить на кого-то "напраслину":).

Или поставить себя в неловкое положение. :)

> Я давно уже зарёкся "выковыривать" 
> что-либо из чьего-то git-репозитария: лично мне на практике проще взять 
> оригинальный tarball от разработчика, или даже за-checkout'ить CVS/SVN и 
> заново пропатчить. Хотя, возможно, я просто туплю...

Давайте попробуем смоделировать ситуацию на конкретном примере, на ваш
выбор.

> а, возможно, потому, 
> что "Разные gear-репозитории устроены ПО-РАЗНОМУ, поскольку практически 
> НИЧЕГО НЕ МЕШАЕТ не мешает мантейнерам организовать свои репозитории так как 
> ИМ удобно".

На практике при всём потенциальном многообразии выделяется три основных
типа устройства репозитория, см. EXAMPLES в gear-rules(5):
http://git.altlinux.org/people/ldv/packages/?p=gear.git;a=blob_plain;f=gear-rules.5.html;hb=html


-- 
ldv

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

Re: [devel] srpms -> gear

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

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

On Tue, Jul 03, 2007 at 02:00:08PM +0300, Led wrote:

L> Из каких репозитариев - не буду говорить, потому как могу ошибиться и 
L> наговорить на кого-то "напраслину":). Я давно уже зарёкся "выковыривать" 
L> что-либо из чьего-то git-репозитария: лично мне на практике проще взять 
L> оригинальный tarball от разработчика, или даже за-checkout'ить CVS/SVN и 
L> заново пропатчить. Хотя, возможно, я просто туплю... а, возможно, потому, 
L> что "Разные gear-репозитории устроены ПО-РАЗНОМУ, поскольку практически 
L> НИЧЕГО НЕ МЕШАЕТ не мешает мантейнерам организовать свои репозитории так как 
L> ИМ удобно".

Давай поспорим что я за 5 минут проиложу произвольный патч к произвольному
пакету в Сизифе, если этот патч прикладывается без конфликтов? И 5 минут +
время на ручной resolve конфликтов, если не прикладывается? При этом для
данной конкретной задаче мне не помешает никакая организация репозитория.

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

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

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

http://freesource.info
----------------------------------------------------------------------------
Ценность программы прямо пропорциональна весу ее "выдачи".

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

Re: [devel] srpms -> gear

[Led]

В сообщении от Tuesday 03 July 2007 14:11:52 Денис Смирнов написал(а):
> On Tue, Jul 03, 2007 at 02:00:08PM +0300, Led wrote:
>
> L> Из каких репозитариев - не буду говорить, потому как могу ошибиться и
> L> наговорить на кого-то "напраслину":). Я давно уже зарёкся "выковыривать"
> L> что-либо из чьего-то git-репозитария: лично мне на практике проще взять
> L> оригинальный tarball от разработчика, или даже за-checkout'ить CVS/SVN и
> L> заново пропатчить. Хотя, возможно, я просто туплю... а, возможно,
> потому, L> что "Разные gear-репозитории устроены ПО-РАЗНОМУ, поскольку
> практически L> НИЧЕГО НЕ МЕШАЕТ не мешает мантейнерам организовать свои
> репозитории так как L> ИМ удобно".
>
> Давай поспорим что я за 5 минут проиложу произвольный патч к произвольному
> пакету в Сизифе, если этот патч прикладывается без конфликтов? И 5 минут +
> время на ручной resolve конфликтов, если не прикладывается? При этом для
> данной конкретной задаче мне не помешает никакая организация репозитория.
>
> Для разработчика проблем с git нет никаких, если он соизволил научиться им
> пользоваться.
>
> Реальная проблема другая -- нужен инструмент не для разработчиков в team,
> а для тех кто со стороны хочет подсмотреть/утащить к себе патчи, тем самым
> убедившись в грамотности сборки у нас.

О чём и речь.

-- 
Led

Re: [devel] srpms -> gear

[Led]

В сообщении от Tuesday 03 July 2007 14:07:29 Денис Смирнов написал(а):
> On Tue, Jul 03, 2007 at 01:26:10PM +0300, Led wrote:
>
> L> я пока не вижу удобного способа "отделить котлеты от мух" в
> git-репозитариях, L> а именно - получить тарболл и патчи к пакету из
> репозитария.
>
> Проведу для всех желающих курс лекций в виде чтения вслух с выражением man
> git-diff. Для членов team скидка.
>
> Мантейнеры они не дураки, по крайней мере мне не известно в team ни одного
> мантейнера-дурака. А чтобы поддерживать патчи их должно быть удобно
> поддерживать, соответственно отделить мух от котлет можно практически
> всегда. Но в некоторых случаях это весьма неочевидная задача.
>
> Кроме того хочу напомнить что предыдущее обвинение в "сокрытии исходников"
> это явная подмена понятий.

Наверное, это "предидущее обвинение" прошло мимо меня - мне "обвинение в 
сокрытии" не приходило:)

> Исходники того что лежит в Сизифе открыты, 
> могут быть неочевидны diff'ы между ними и оригиналом. Некоторые пакеты уже
> тянут скорее на форк, чем на "пакет плюс пара патчей". Естественно
> мантейнер заинтересован в прохождении патчей в апстрим, но иногда это
> невозможно по различным принципиальным проблемам -- как то нарушение
> патентов на алгоритмы (на кои мы, как живущие в нормальной стране а не США
> может внимания не обращать), более жесткая политика безопасности, и т.д.



-- 
Led

Re: [devel] srpms -> gear

[Alexey I. Froloff]

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

* Alexey Gladkov <legion@> [070703 02:01]:
> > src.rpm - это фактически snapshot, результат применения gear к
> > определённому коммиту.  Как вариант, можно придумать не сильно
> > обременяющий сервер способ выдавать пригодные для сборки hasher'ом
> > tarball'ы прямо из gear-репозитория.
А я даже патчик к gitweb рисовал...  Должен быть в рассылке.

> git-archive --format=tar ?
Нет, просто gear.

-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/

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

Re: [devel] srpms -> gear

[Anton Farygin]

Aleksey Novodvorsky wrote:
> On 7/3/07, Led <ledest@gmail.com> wrote:
>> В сообщении от Tuesday 03 July 2007 12:28:36 Dmitry V. Levin написал(а):
>>> On Tue, Jul 03, 2007 at 12:23:29PM +0300, Michael Shigorin wrote:
>>>> On Tue, Jul 03, 2007 at 12:18:27AM +0400, Dmitry V. Levin wrote:
>>>>> Смотря как переносить.  Как вы можете видеть, я пока ничего не
>>>>> форсирую, хочу чтобы как можно больше людей привыкло к
>>>>> относительно новому инструментарию.
>>>> У меня пока привыкание остановилось на подходе к apache и xmms
>>>> (2 solo: помню, но ещё всё так же не смотрел -- видимо, уже на
>>>> кофнференции).  Поскольку патчи из разных мест, которые
>>>> поддерживаю не я, пока возможней поддерживать со старым добрым
>>>> src.rpm, чем в гите.  Проблема в том, что эти два апстрима,
>>>> мягко говоря, консервативные и продавить их туда уже не особо
>>>> реально.
>>> gear-репозиторий, который получается на выходе gear-srpmimport,
>>> ни чуть не сложнее srpm-пакета, верно?
>>>
>>>>> Видимого смысла в srpm-паетах после миграции на
>>>>> gear-репозитории не будет.
>>>> Было бы всё-таки хорошо иметь какой-то простой вариант понять,
>>>> чем отличается пакет от upstream tarball.  Причём не глазами
>>>> разработчика (им проще), а скорее глазами опытного админа.
>>> gitweb?
>>>
>>>> Повторюсь, если мы собираемся заниматься серверами и иметь
>>>> толковые инструменты их администрирования -- следует привлекать
>>>> опытных админов, поскольку "толк" в инструментах -- это как раз
>>>> замороженный в бэкендах опыт администрирования, как вот и толк
>>>> в пакетах -- замороженный в спеках опыт сборки.
>>> Среди нас есть опытные админы, не являющиеся по совместительству
>>> разработчиками?  Если нет, то как ты предлагаешь моделировать их нужды?
>> Формально - всё верно. Но почему-то всё больше кажется, что всё идёт к тому,
>> что "исходники - только по требованию" и формально доступ "по требованию" к
>> ним будет... теоретически...
> 
> Давайте отделять мух от котлет. Здесь нет никого, заинтересованного в
> сокрытии исходников. Наоборот.  Но форма предоставлени исходников
> может меняться. Важно, чтобы она была удобной, а не такой же, как
> всегда.

Я кстати согласен с Майк'ом - очень хочется иметь возможность получить 
один или несколько патчей по сравнению с mainstream.

Сам пользуюсь и mainstream ссылки отправляю.. но я не храню исходники в 
развёрнутом виде в git'е.

Re: [devel] srpms -> gear

[Anton Farygin]

Led wrote:
> В сообщении от Tuesday 03 July 2007 13:40:55 Dmitry V. Levin написал(а):
>> On Tue, Jul 03, 2007 at 01:26:10PM +0300, Led wrote:
>>> В сообщении от Tuesday 03 July 2007 13:02:34 Aleksey Novodvorsky
>>> написал(а):
>> [...]
>>
>>>> Давайте отделять мух от котлет.
>>> я пока не вижу удобного способа "отделить котлеты от мух" в
>>> git-репозитариях, а именно - получить тарболл и патчи к пакету из
>>> репозитария.
>> Разные gear-репозитории устроены по-разному, поскольку практически ничего
>> не мешает мантейнерам организовать свои репозитории так как им удобно.
>>
>> Из какого именно репозитория вы не смогли получить тарболл и/или патчи?
> 
> Я не говорил, что "не смог". Я говорил: "не вижу УДОБНОГО способа" (и далее по 
> тексту).
> 
> Из каких репозитариев - не буду говорить, потому как могу ошибиться и 
> наговорить на кого-то "напраслину":). Я давно уже зарёкся "выковыривать" 
> что-либо из чьего-то git-репозитария: лично мне на практике проще взять 
> оригинальный tarball от разработчика, или даже за-checkout'ить CVS/SVN и 
> заново пропатчить. Хотя, возможно, я просто туплю... а, возможно, потому, 
> что "Разные gear-репозитории устроены ПО-РАЗНОМУ, поскольку практически 
> НИЧЕГО НЕ МЕШАЕТ не мешает мантейнерам организовать свои репозитории так как 
> ИМ удобно".
> 

Точно знаю что из моего psi0.11 оригинальный тарболл плюс патчи получить 
нереально.

Re: [devel] srpms -> gear

[Anton Farygin]

Денис Смирнов wrote:
> On Tue, Jul 03, 2007 at 02:00:08PM +0300, Led wrote:
> 
> L> Из каких репозитариев - не буду говорить, потому как могу ошибиться и 
> L> наговорить на кого-то "напраслину":). Я давно уже зарёкся "выковыривать" 
> L> что-либо из чьего-то git-репозитария: лично мне на практике проще взять 
> L> оригинальный tarball от разработчика, или даже за-checkout'ить CVS/SVN и 
> L> заново пропатчить. Хотя, возможно, я просто туплю... а, возможно, потому, 
> L> что "Разные gear-репозитории устроены ПО-РАЗНОМУ, поскольку практически 
> L> НИЧЕГО НЕ МЕШАЕТ не мешает мантейнерам организовать свои репозитории так как 
> L> ИМ удобно".
> 
> Давай поспорим что я за 5 минут проиложу произвольный патч к произвольному
> пакету в Сизифе, если этот патч прикладывается без конфликтов? И 5 минут +
> время на ручной resolve конфликтов, если не прикладывается? При этом для
> данной конкретной задаче мне не помешает никакая организация репозитория.
> 
> Для разработчика проблем с git нет никаких, если он соизволил научиться им
> пользоваться.
> 
> Реальная проблема другая -- нужен инструмент не для разработчиков в team,
> а для тех кто со стороны хочет подсмотреть/утащить к себе патчи, тем самым
> убедившись в грамотности сборки у нас.

Денис, попробуй пожалуйста за пять минут приложить патч к 
kernel-image-std-smp ;)

патч любой, на твой вкус,

Re: [devel] gear vs patches

[Anton Farygin]

Michael Shigorin wrote:
> On Tue, Jul 03, 2007 at 01:09:03AM +0400, Anton Farygin wrote:
>>> О, народ уже начал наступать на грабли монолитных патчей или 
>>> неапстримных тарболов родом из git.
>> Лично меня вполне устраивает подход из пакета ImageMagick с 
>> оригинальными тарболлами + патчами.
> 
> Ммм... как вариант, а это собирается gear? (хотя 80% вкусности
> git по работе с бранчами улетает -- с другой стороны, пока никто
> не описал внятной success story по их использованию, а по уже 
> пролопаченному репозиторию пойди пойми, как он был получен)
> 

Конечно собирается, я же собираю.

Re: [devel] gear vs patches

[Anton Farygin]

Dmitry V. Levin wrote:
> On Tue, Jul 03, 2007 at 12:28:35PM +0300, Michael Shigorin wrote:
>> On Tue, Jul 03, 2007 at 01:09:03AM +0400, Anton Farygin wrote:
>>>> О, народ уже начал наступать на грабли монолитных патчей или 
>>>> неапстримных тарболов родом из git.
>>> Лично меня вполне устраивает подход из пакета ImageMagick с 
>>> оригинальными тарболлами + патчами.
>> Ммм... как вариант, а это собирается gear?
> 
> Да, конечно, так работает "gear-srpmimport --no-unpack",
> но я настоятельно рекомендую хранить upstream'ные tar-архивы
> в распакованном виде.

Пока не будет понятен механизм действия при выходе новой версии - это 
unreal.

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

Re: [devel] gear vs patches

[Pavlov Konstantin]

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

On Tue, Jul 03, 2007 at 06:35:49PM +0400, Anton Farygin wrote:
> Dmitry V. Levin wrote:
> > On Tue, Jul 03, 2007 at 12:28:35PM +0300, Michael Shigorin wrote:
> >> On Tue, Jul 03, 2007 at 01:09:03AM +0400, Anton Farygin wrote:
> >>>> О, народ уже начал наступать на грабли монолитных патчей или 
> >>>> неапстримных тарболов родом из git.
> >>> Лично меня вполне устраивает подход из пакета ImageMagick с 
> >>> оригинальными тарболлами + патчами.
> >> Ммм... как вариант, а это собирается gear?
> > 
> > Да, конечно, так работает "gear-srpmimport --no-unpack",
> > но я настоятельно рекомендую хранить upstream'ные tar-архивы
> > в распакованном виде.
> 
> Пока не будет понятен механизм действия при выходе новой версии - это 
> unreal.
> 
> Вот есть у меня текущий ImageMagick, вышла новая версия. Мои действия ? 
> (я не беру ImageMagick из их CVS, а скачиваю тарболл).

Создай отдельный бранч (можно даже из твоего master) только с подкаталогом
ImageMagick путем удаления остального барахла.
Далее в master: git pull -s ours . upstream
Далее в upstream: вместо старого подкаталога ImageMagick кладем новый из
нового тарболла, комиттим, переходим в master и делаем pull из upstream.
Правим спек на версии, пишем ченджлог, комиттим. собираем.

-- 
 * svd совсем с ума сошёл.. для отсылки мессаги по асе нажимает C-c C-c 
<mouse> svd: самое тяжёлое, когда приходится что-то делать в виндах.
        Самое тяжёлое, что нужно нажимать всякие там C-C, C-V вместо
        средней кнопки мыши...

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

Re: [devel] srpms -> gear

[Pavlov Konstantin]

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

On Tue, Jul 03, 2007 at 06:32:13PM +0400, Anton Farygin wrote:

> > Я не говорил, что "не смог". Я говорил: "не вижу УДОБНОГО способа" (и далее по 
> > тексту).
> > 
> > Из каких репозитариев - не буду говорить, потому как могу ошибиться и 
> > наговорить на кого-то "напраслину":). Я давно уже зарёкся "выковыривать" 
> > что-либо из чьего-то git-репозитария: лично мне на практике проще взять 
> > оригинальный tarball от разработчика, или даже за-checkout'ить CVS/SVN и 
> > заново пропатчить. Хотя, возможно, я просто туплю... а, возможно, потому, 
> > что "Разные gear-репозитории устроены ПО-РАЗНОМУ, поскольку практически 
> > НИЧЕГО НЕ МЕШАЕТ не мешает мантейнерам организовать свои репозитории так как 
> > ИМ удобно".
> > 
> 
> Точно знаю что из моего psi0.11 оригинальный тарболл плюс патчи получить 
> нереально.

В чем сложность сделать отдельный бранч с исходниками из SVN и сделать
дифф между этим бранчем и твоим master?

-- 
(Да, мы выпили много хорошего, крепкого чая, когда это придумывали :) )
		-- voins in devel@

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

Re: [devel] srpms -> gear

[Dmitry V. Levin]

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

On Tue, Jul 03, 2007 at 06:30:46PM +0400, Anton Farygin wrote:
[...]
> Я кстати согласен с Майк'ом - очень хочется иметь возможность получить 
> один или несколько патчей по сравнению с mainstream.

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


-- 
ldv

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

Re: [devel] gear vs patches

[Alexey Gladkov]

Anton Farygin пишет:
> Пока не будет понятен механизм действия при выходе новой версии - это 
> unreal.
> 
> Вот есть у меня текущий ImageMagick, вышла новая версия. Мои действия ? 
> (я не беру ImageMagick из их CVS, а скачиваю тарболл).

Для тарболлов (или других архивов) есть gear-update.

-- 
Rgrds, legion

Re: [devel] srpms -> gear

[Dmitry V. Levin]

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

On Tue, Jul 03, 2007 at 06:33:40PM +0400, Anton Farygin wrote:
> Денис Смирнов wrote:
[...]
> > Давай поспорим что я за 5 минут проиложу произвольный патч к произвольному
> > пакету в Сизифе, если этот патч прикладывается без конфликтов? И 5 минут +
> > время на ручной resolve конфликтов, если не прикладывается? При этом для
> > данной конкретной задаче мне не помешает никакая организация репозитория.
> > 
> > Для разработчика проблем с git нет никаких, если он соизволил научиться им
> > пользоваться.
> > 
> > Реальная проблема другая -- нужен инструмент не для разработчиков в team,
> > а для тех кто со стороны хочет подсмотреть/утащить к себе патчи, тем самым
> > убедившись в грамотности сборки у нас.
> 
> Денис, попробуй пожалуйста за пять минут приложить патч к 
> kernel-image-std-smp ;)

Если на скорую руку, то это тривиально:
$ git clone git://git.altlinux.org/people/vsu/packages/kernel-image-2.6.18.git
$ git checkout kernel-image-std-smp
$ patch <patch-source
$ git commit


-- 
ldv

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

Re: [devel] srpms -> gear

[Pavlov Konstantin]

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

On Tue, Jul 03, 2007 at 06:38:18PM +0400, Pavlov Konstantin wrote:
> On Tue, Jul 03, 2007 at 06:32:13PM +0400, Anton Farygin wrote:
> 
> > > Я не говорил, что "не смог". Я говорил: "не вижу УДОБНОГО способа" (и далее по 
> > > тексту).
> > > 
> > > Из каких репозитариев - не буду говорить, потому как могу ошибиться и 
> > > наговорить на кого-то "напраслину":). Я давно уже зарёкся "выковыривать" 
> > > что-либо из чьего-то git-репозитария: лично мне на практике проще взять 
> > > оригинальный tarball от разработчика, или даже за-checkout'ить CVS/SVN и 
> > > заново пропатчить. Хотя, возможно, я просто туплю... а, возможно, потому, 
> > > что "Разные gear-репозитории устроены ПО-РАЗНОМУ, поскольку практически 
> > > НИЧЕГО НЕ МЕШАЕТ не мешает мантейнерам организовать свои репозитории так как 
> > > ИМ удобно".
> > > 
> > 
> > Точно знаю что из моего psi0.11 оригинальный тарболл плюс патчи получить 
> > нереально.
> 
> В чем сложность сделать отдельный бранч с исходниками из SVN и сделать
> дифф между этим бранчем и твоим master?

Ну в общем:
$ git clone git.alt:/people/rider/packages/psi0.11.git
$ cd psi0.11
$ git log
 смотрим какой коммит в svn ты использовал
$ git-svn init http://svn.psi-im.org/psi/trunk
$ git-svn fetch -r 721
$ git diff refs/remotes/git-svn > alt.patch

ну и все в общем-то.

-- 
Дык и мне mkisofs+cdrecord за глаза, ты не подумай :)  Но если
влом -- то хорошо, когда есть тулзень, которая маны за тебя уже     
почитала.
		-- mike in smoke-room@

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

Re: [devel] srpms -> gear

[Alexey Rusakov]

On Tue, 3 Jul 2007 18:38:37 +0400
Dmitry V. Levin wrote:

> On Tue, Jul 03, 2007 at 06:30:46PM +0400, Anton Farygin wrote:
> [...]
> > Я кстати согласен с Майк'ом - очень хочется иметь возможность получить 
> > один или несколько патчей по сравнению с mainstream.
> 
> Это тривиально, если соблюдается простое правило
> "один коммит не содержит логически несвязанных патчей";
Запихивание в один коммит логически несвязанных изменений говорит о
неумении пользоваться системами управления исходным кодом в целом.
Фактически справедливо следующее: при условии наличия у мейнтейнера навыков
правильного использования git и знания конкретных коммитов патчи
генерируются достаточно легко. "Опытный админ" должен быть в состоянии без
труда справиться с этой задачей, если у него есть входная информация в
виде ссылки на коммит или набор коммитов (кстати, автоматизировать
генерацию патча соответствующего набору коммитов было бы нехудо).


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

Re: [devel] gear vs patches

[Dmitry V. Levin]

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

On Tue, Jul 03, 2007 at 06:35:49PM +0400, Anton Farygin wrote:
[...]
> Вот есть у меня текущий ImageMagick, вышла новая версия. Мои действия ? 
> (я не беру ImageMagick из их CVS, а скачиваю тарболл).

В зависимости от того, как устроен gear-репозиторий,
есть 2 проработанных варианта обновления из тарболлов:

1. В репозитории все изменения оформлены в виде отдельных патчей,
upstream'ный исходный код хранится _без_ изменений, каждый тарболл развёрнут
в индивидуальном подкаталоге (такую схему использует gear-srpmimport).
Тогда с помощью утилиты gear-update(1) можно обновлять подкаталоги из
тарболлов.
Пример: http://git.altlinux.org/people/ldv/packages/?p=gcc4.1.git

2. В репозитории есть изменения, которые приложены, т.е. есть подкаталоги,
которые содержат upstream'ный исходный код _с_ изменениями.
Тогда каждый такой каталог следует поместить в отдельный бранч для того,
чтобы хранить исходный код без изменений отдельно, обновлять его с
помощью gear-update(1) по первому варианту.  С помощью "git pull"
обновления с этих бранчей по мере надобности вливаются в основной бранч.
Пример: http://git.altlinux.org/people/ldv/packages/?p=file.git


-- 
ldv

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

Re: [devel] gear vs patches

[Dmitry V. Levin]

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

On Tue, Jul 03, 2007 at 07:00:00PM +0400, Dmitry V. Levin wrote:
> On Tue, Jul 03, 2007 at 06:35:49PM +0400, Anton Farygin wrote:
> [...]
> > Вот есть у меня текущий ImageMagick, вышла новая версия. Мои действия ? 
> > (я не беру ImageMagick из их CVS, а скачиваю тарболл).
> 
> В зависимости от того, как устроен gear-репозиторий,
> есть 2 проработанных варианта обновления из тарболлов:
> 
> 1. В репозитории все изменения оформлены в виде отдельных патчей,
> upstream'ный исходный код хранится _без_ изменений, каждый тарболл развёрнут
> в индивидуальном подкаталоге (такую схему использует gear-srpmimport).
> Тогда с помощью утилиты gear-update(1) можно обновлять подкаталоги из
> тарболлов.
> Пример: http://git.altlinux.org/people/ldv/packages/?p=gcc4.1.git
> 
> 2. В репозитории есть изменения, которые приложены, т.е. есть подкаталоги,
> которые содержат upstream'ный исходный код _с_ изменениями.
> Тогда каждый такой каталог следует поместить в отдельный бранч для того,
> чтобы хранить исходный код без изменений отдельно, обновлять его с
> помощью gear-update(1) по первому варианту.  С помощью "git pull"
> обновления с этих бранчей по мере надобности вливаются в основной бранч.
> Пример: http://git.altlinux.org/people/ldv/packages/?p=file.git

Добавил ещё одно правило для http-сервера, теперь можно использовать более
естественные адреса, например:
http://git.altlinux.org/people/ldv/packages/file.git


-- 
ldv

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

Re: [devel] srpms -> gear

[Anton Farygin]

Dmitry V. Levin wrote:
> On Tue, Jul 03, 2007 at 06:33:40PM +0400, Anton Farygin wrote:
>> Денис Смирнов wrote:
> [...]
>>> Давай поспорим что я за 5 минут проиложу произвольный патч к произвольному
>>> пакету в Сизифе, если этот патч прикладывается без конфликтов? И 5 минут +
>>> время на ручной resolve конфликтов, если не прикладывается? При этом для
>>> данной конкретной задаче мне не помешает никакая организация репозитория.
>>>
>>> Для разработчика проблем с git нет никаких, если он соизволил научиться им
>>> пользоваться.
>>>
>>> Реальная проблема другая -- нужен инструмент не для разработчиков в team,
>>> а для тех кто со стороны хочет подсмотреть/утащить к себе патчи, тем самым
>>> убедившись в грамотности сборки у нас.
>> Денис, попробуй пожалуйста за пять минут приложить патч к 
>> kernel-image-std-smp ;)
> 
> Если на скорую руку, то это тривиально:
> $ git clone git://git.altlinux.org/people/vsu/packages/kernel-image-2.6.18.git
> $ git checkout kernel-image-std-smp
> $ patch <patch-source
> $ git commit

А как же то, что все патчи в отдельных бранчах ? или на это уже забили ?

Re: [devel] srpms -> gear

[Anton Farygin]

Pavlov Konstantin wrote:
> On Tue, Jul 03, 2007 at 06:32:13PM +0400, Anton Farygin wrote:
> 
>>> Я не говорил, что "не смог". Я говорил: "не вижу УДОБНОГО способа" (и далее по 
>>> тексту).
>>>
>>> Из каких репозитариев - не буду говорить, потому как могу ошибиться и 
>>> наговорить на кого-то "напраслину":). Я давно уже зарёкся "выковыривать" 
>>> что-либо из чьего-то git-репозитария: лично мне на практике проще взять 
>>> оригинальный tarball от разработчика, или даже за-checkout'ить CVS/SVN и 
>>> заново пропатчить. Хотя, возможно, я просто туплю... а, возможно, потому, 
>>> что "Разные gear-репозитории устроены ПО-РАЗНОМУ, поскольку практически 
>>> НИЧЕГО НЕ МЕШАЕТ не мешает мантейнерам организовать свои репозитории так как 
>>> ИМ удобно".
>>>
>> Точно знаю что из моего psi0.11 оригинальный тарболл плюс патчи получить 
>> нереально.
> 
> В чем сложность сделать отдельный бранч с исходниками из SVN и сделать
> дифф между этим бранчем и твоим master?

Мне, как мантейнеру, пушить это лень.

Да и gitweb по моему дифф между бранчами не умеет выкладывать

Re: [devel] srpms -> gear

[Anton Farygin]

Pavlov Konstantin wrote:
> On Tue, Jul 03, 2007 at 06:38:18PM +0400, Pavlov Konstantin wrote:
>> On Tue, Jul 03, 2007 at 06:32:13PM +0400, Anton Farygin wrote:
>>
>>>> Я не говорил, что "не смог". Я говорил: "не вижу УДОБНОГО способа" (и далее по 
>>>> тексту).
>>>>
>>>> Из каких репозитариев - не буду говорить, потому как могу ошибиться и 
>>>> наговорить на кого-то "напраслину":). Я давно уже зарёкся "выковыривать" 
>>>> что-либо из чьего-то git-репозитария: лично мне на практике проще взять 
>>>> оригинальный tarball от разработчика, или даже за-checkout'ить CVS/SVN и 
>>>> заново пропатчить. Хотя, возможно, я просто туплю... а, возможно, потому, 
>>>> что "Разные gear-репозитории устроены ПО-РАЗНОМУ, поскольку практически 
>>>> НИЧЕГО НЕ МЕШАЕТ не мешает мантейнерам организовать свои репозитории так как 
>>>> ИМ удобно".
>>>>
>>> Точно знаю что из моего psi0.11 оригинальный тарболл плюс патчи получить 
>>> нереально.
>> В чем сложность сделать отдельный бранч с исходниками из SVN и сделать
>> дифф между этим бранчем и твоим master?
> 
> Ну в общем:
> $ git clone git.alt:/people/rider/packages/psi0.11.git
> $ cd psi0.11
> $ git log
>  смотрим какой коммит в svn ты использовал
> $ git-svn init http://svn.psi-im.org/psi/trunk
> $ git-svn fetch -r 721
> $ git diff refs/remotes/git-svn > alt.patch
> 
> ну и все в общем-то.

Ужас.. нормальный человек с этим без здоровой документации не разберётся.

Re: [devel] srpms -> gear

[Anton Farygin]

Dmitry V. Levin wrote:
> On Tue, Jul 03, 2007 at 06:30:46PM +0400, Anton Farygin wrote:
> [...]
>> Я кстати согласен с Майк'ом - очень хочется иметь возможность получить 
>> один или несколько патчей по сравнению с mainstream.
> 
> Это тривиально, если соблюдается простое правило
> "один коммит не содержит логически несвязанных патчей";
> в противном случае есть риск получить удовольствие собирать патч по разным
> коммитам, в которых находятся по несколько кусков логически несвязанных
> патчей.

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

Re: [devel] gear vs patches

[Anton Farygin]

Pavlov Konstantin wrote:
> On Tue, Jul 03, 2007 at 06:35:49PM +0400, Anton Farygin wrote:
>> Dmitry V. Levin wrote:
>>> On Tue, Jul 03, 2007 at 12:28:35PM +0300, Michael Shigorin wrote:
>>>> On Tue, Jul 03, 2007 at 01:09:03AM +0400, Anton Farygin wrote:
>>>>>> О, народ уже начал наступать на грабли монолитных патчей или 
>>>>>> неапстримных тарболов родом из git.
>>>>> Лично меня вполне устраивает подход из пакета ImageMagick с 
>>>>> оригинальными тарболлами + патчами.
>>>> Ммм... как вариант, а это собирается gear?
>>> Да, конечно, так работает "gear-srpmimport --no-unpack",
>>> но я настоятельно рекомендую хранить upstream'ные tar-архивы
>>> в распакованном виде.
>> Пока не будет понятен механизм действия при выходе новой версии - это 
>> unreal.
>>
>> Вот есть у меня текущий ImageMagick, вышла новая версия. Мои действия ? 
>> (я не беру ImageMagick из их CVS, а скачиваю тарболл).
> 
> Создай отдельный бранч (можно даже из твоего master) только с подкаталогом
> ImageMagick путем удаления остального барахла.
> Далее в master: git pull -s ours . upstream
> Далее в upstream: вместо старого подкаталога ImageMagick кладем новый из
> нового тарболла, комиттим, переходим в master и делаем pull из upstream.
> Правим спек на версии, пишем ченджлог, комиттим. собираем.

Не понял, а что делать со старым каталогом ? как удалять/добавлять файлы ?

Re: [devel] srpms -> gear

[Dmitry V. Levin]

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

On Tue, Jul 03, 2007 at 08:54:41PM +0400, Anton Farygin wrote:
> Dmitry V. Levin wrote:
> > On Tue, Jul 03, 2007 at 06:33:40PM +0400, Anton Farygin wrote:
> >> Денис Смирнов wrote:
> > [...]
> >>> Давай поспорим что я за 5 минут проиложу произвольный патч к произвольному
> >>> пакету в Сизифе, если этот патч прикладывается без конфликтов? И 5 минут +
> >>> время на ручной resolve конфликтов, если не прикладывается? При этом для
> >>> данной конкретной задаче мне не помешает никакая организация репозитория.
> >>>
> >>> Для разработчика проблем с git нет никаких, если он соизволил научиться им
> >>> пользоваться.
> >>>
> >>> Реальная проблема другая -- нужен инструмент не для разработчиков в team,
> >>> а для тех кто со стороны хочет подсмотреть/утащить к себе патчи, тем самым
> >>> убедившись в грамотности сборки у нас.
> >> Денис, попробуй пожалуйста за пять минут приложить патч к 
> >> kernel-image-std-smp ;)
> > 
> > Если на скорую руку, то это тривиально:
> > $ git clone git://git.altlinux.org/people/vsu/packages/kernel-image-2.6.18.git
> > $ git checkout kernel-image-std-smp
> > $ patch <patch-source
> > $ git commit
> 
> А как же то, что все патчи в отдельных бранчах ? или на это уже забили ?

Патчи разрабатываются в отдельных бранчах, а потом вливаются в
kernel-image-std-smp.

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


-- 
ldv

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

Re: [devel] srpms -> gear

[Dmitry V. Levin]

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

On Tue, Jul 03, 2007 at 08:56:11PM +0400, Anton Farygin wrote:
> Pavlov Konstantin wrote:
> > On Tue, Jul 03, 2007 at 06:38:18PM +0400, Pavlov Konstantin wrote:
> >> On Tue, Jul 03, 2007 at 06:32:13PM +0400, Anton Farygin wrote:
[...]
> >>> Точно знаю что из моего psi0.11 оригинальный тарболл плюс патчи получить 
> >>> нереально.
> >> В чем сложность сделать отдельный бранч с исходниками из SVN и сделать
> >> дифф между этим бранчем и твоим master?
> > 
> > Ну в общем:
> > $ git clone git.alt:/people/rider/packages/psi0.11.git
> > $ cd psi0.11
> > $ git log
> >  смотрим какой коммит в svn ты использовал
> > $ git-svn init http://svn.psi-im.org/psi/trunk
> > $ git-svn fetch -r 721
> > $ git diff refs/remotes/git-svn > alt.patch
> > 
> > ну и все в общем-то.
> 
> Ужас.. нормальный человек с этим без здоровой документации не разберётся.

Так ведь ты сам организовал _этот_ ужас.  Если бы в репозитории был бы
бранч с исходным кодом из svn, то можно было бы сразу применить git diff.


-- 
ldv

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

Re: [devel] gear vs patches

[Pavlov Konstantin]

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

On Tue, Jul 03, 2007 at 08:59:10PM +0400, Anton Farygin wrote:
> Pavlov Konstantin wrote:
> > On Tue, Jul 03, 2007 at 06:35:49PM +0400, Anton Farygin wrote:
> >> Dmitry V. Levin wrote:
> >>> On Tue, Jul 03, 2007 at 12:28:35PM +0300, Michael Shigorin wrote:
> >>>> On Tue, Jul 03, 2007 at 01:09:03AM +0400, Anton Farygin wrote:
> >>>>>> О, народ уже начал наступать на грабли монолитных патчей или 
> >>>>>> неапстримных тарболов родом из git.
> >>>>> Лично меня вполне устраивает подход из пакета ImageMagick с 
> >>>>> оригинальными тарболлами + патчами.
> >>>> Ммм... как вариант, а это собирается gear?
> >>> Да, конечно, так работает "gear-srpmimport --no-unpack",
> >>> но я настоятельно рекомендую хранить upstream'ные tar-архивы
> >>> в распакованном виде.
> >> Пока не будет понятен механизм действия при выходе новой версии - это 
> >> unreal.
> >>
> >> Вот есть у меня текущий ImageMagick, вышла новая версия. Мои действия ? 
> >> (я не беру ImageMagick из их CVS, а скачиваю тарболл).
> > 
> > Создай отдельный бранч (можно даже из твоего master) только с подкаталогом
> > ImageMagick путем удаления остального барахла.
> > Далее в master: git pull -s ours . upstream
> > Далее в upstream: вместо старого подкаталога ImageMagick кладем новый из
> > нового тарболла, комиттим, переходим в master и делаем pull из upstream.
> > Правим спек на версии, пишем ченджлог, комиттим. собираем.
> 
> Не понял, а что делать со старым каталогом ? как удалять/добавлять файлы ?

rm -rf ImageMagick
tar xf ImageMagick-newversion.tar.gz
mv ImageMagick-newversion ImageMagick
убьем удаленные файлы:
git-ls-files --deleted -z | git-update-index --remove --verbose -z --stdin
добавим новопоявившиеся:
find ImageMagick -type f -print0 |xargs -0 git-update-index --add
закомиттим, git-commit.

Для удаления файла -- git-rm, для добавления -- git-add

В принципе это наверно все делается gear-archive'ом, но я пока не смотрел
в него.

-- 
Я не понимаю, как такое могло получиться; неужели никто из packager'ов не
использует freeciv в своей повседневной работе? :)
		-- ldv in sisyphus@

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

Re: [devel] srpms -> gear

[Pavlov Konstantin]

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

On Tue, Jul 03, 2007 at 08:55:27PM +0400, Anton Farygin wrote:
> Pavlov Konstantin wrote:
> > On Tue, Jul 03, 2007 at 06:32:13PM +0400, Anton Farygin wrote:
> > 
> >>> Я не говорил, что "не смог". Я говорил: "не вижу УДОБНОГО способа" (и далее по 
> >>> тексту).
> >>>
> >>> Из каких репозитариев - не буду говорить, потому как могу ошибиться и 
> >>> наговорить на кого-то "напраслину":). Я давно уже зарёкся "выковыривать" 
> >>> что-либо из чьего-то git-репозитария: лично мне на практике проще взять 
> >>> оригинальный tarball от разработчика, или даже за-checkout'ить CVS/SVN и 
> >>> заново пропатчить. Хотя, возможно, я просто туплю... а, возможно, потому, 
> >>> что "Разные gear-репозитории устроены ПО-РАЗНОМУ, поскольку практически 
> >>> НИЧЕГО НЕ МЕШАЕТ не мешает мантейнерам организовать свои репозитории так как 
> >>> ИМ удобно".
> >>>
> >> Точно знаю что из моего psi0.11 оригинальный тарболл плюс патчи получить 
> >> нереально.
> > 
> > В чем сложность сделать отдельный бранч с исходниками из SVN и сделать
> > дифф между этим бранчем и твоим master?
> 
> Мне, как мантейнеру, пушить это лень.
> 
> Да и gitweb по моему дифф между бранчами не умеет выкладывать

gitweb, возможно, и не умеет, gitarella, кажется, умела.

-- 
Не надо засорять список рассылки offtopic'ами,
для этого есть другие рассылки @altlinux.ru
		-- ldv in sisyphus@

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

Re: [devel] srpms -> gear

[Dmitry V. Levin]

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

On Tue, Jul 03, 2007 at 08:57:10PM +0400, Anton Farygin wrote:
> Dmitry V. Levin wrote:
> > On Tue, Jul 03, 2007 at 06:30:46PM +0400, Anton Farygin wrote:
> > [...]
> >> Я кстати согласен с Майк'ом - очень хочется иметь возможность получить 
> >> один или несколько патчей по сравнению с mainstream.
> > 
> > Это тривиально, если соблюдается простое правило
> > "один коммит не содержит логически несвязанных патчей";
> > в противном случае есть риск получить удовольствие собирать патч по разным
> > коммитам, в которых находятся по несколько кусков логически несвязанных
> > патчей.
> 
> Такого не бывает - видимо при очередном обновлении патчи могут поехать.

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

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


-- 
ldv

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

Re: [devel] gear vs patches

[Dmitry V. Levin]

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

On Tue, Jul 03, 2007 at 09:02:02PM +0400, Pavlov Konstantin wrote:
> On Tue, Jul 03, 2007 at 08:59:10PM +0400, Anton Farygin wrote:
> > Pavlov Konstantin wrote:
> > > On Tue, Jul 03, 2007 at 06:35:49PM +0400, Anton Farygin wrote:
> > >> Dmitry V. Levin wrote:
> > >>> On Tue, Jul 03, 2007 at 12:28:35PM +0300, Michael Shigorin wrote:
> > >>>> On Tue, Jul 03, 2007 at 01:09:03AM +0400, Anton Farygin wrote:
> > >>>>>> О, народ уже начал наступать на грабли монолитных патчей или 
> > >>>>>> неапстримных тарболов родом из git.
> > >>>>> Лично меня вполне устраивает подход из пакета ImageMagick с 
> > >>>>> оригинальными тарболлами + патчами.
> > >>>> Ммм... как вариант, а это собирается gear?
> > >>> Да, конечно, так работает "gear-srpmimport --no-unpack",
> > >>> но я настоятельно рекомендую хранить upstream'ные tar-архивы
> > >>> в распакованном виде.
> > >> Пока не будет понятен механизм действия при выходе новой версии - это 
> > >> unreal.
> > >>
> > >> Вот есть у меня текущий ImageMagick, вышла новая версия. Мои действия ? 
> > >> (я не беру ImageMagick из их CVS, а скачиваю тарболл).
> > > 
> > > Создай отдельный бранч (можно даже из твоего master) только с подкаталогом
> > > ImageMagick путем удаления остального барахла.
> > > Далее в master: git pull -s ours . upstream
> > > Далее в upstream: вместо старого подкаталога ImageMagick кладем новый из
> > > нового тарболла, комиттим, переходим в master и делаем pull из upstream.
> > > Правим спек на версии, пишем ченджлог, комиттим. собираем.
> > 
> > Не понял, а что делать со старым каталогом ? как удалять/добавлять файлы ?
> 
> rm -rf ImageMagick
> tar xf ImageMagick-newversion.tar.gz
> mv ImageMagick-newversion ImageMagick
> убьем удаленные файлы:
> git-ls-files --deleted -z | git-update-index --remove --verbose -z --stdin
> добавим новопоявившиеся:
> find ImageMagick -type f -print0 |xargs -0 git-update-index --add
> закомиттим, git-commit.
> 
> Для удаления файла -- git-rm, для добавления -- git-add
> 
> В принципе это наверно все делается gear-archive'ом, но я пока не смотрел
> в него.

gear-update'ом.


-- 
ldv

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

Re: [devel] srpms -> gear

[Anton Farygin]

Dmitry V. Levin wrote:
> On Tue, Jul 03, 2007 at 08:57:10PM +0400, Anton Farygin wrote:
>> Dmitry V. Levin wrote:
>>> On Tue, Jul 03, 2007 at 06:30:46PM +0400, Anton Farygin wrote:
>>> [...]
>>>> Я кстати согласен с Майк'ом - очень хочется иметь возможность получить 
>>>> один или несколько патчей по сравнению с mainstream.
>>> Это тривиально, если соблюдается простое правило
>>> "один коммит не содержит логически несвязанных патчей";
>>> в противном случае есть риск получить удовольствие собирать патч по разным
>>> коммитам, в которых находятся по несколько кусков логически несвязанных
>>> патчей.
>> Такого не бывает - видимо при очередном обновлении патчи могут поехать.
> 
> Перефразируя себя нескольколетней давности,
> свойство патчей "поехать при очередном обновлении" - это важное
> преимущество, а вовсе не недостаток, как полагают многие.
> 
> Если патч нужно обновить, то его нужно обновить.
> Не надо одним коммитом обновлять разные патчи по частям.

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

Мне теперь немного стало понятнее, но всё равно есть проблема - дорогой 
трафик. Качать например git ядра - 100 с лишним метров..

Re: [devel] srpms -> gear

[Valery V. Inozemtsev]

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

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

я об этом с самого начала говорил

>
> Мне теперь немного стало понятнее,

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

> но всё равно есть проблема - дорогой 
> трафик. Качать например git ядра - 100 с лишним метров..

-- 
Valery V. Inozemtsev

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] srpms -> gear

[Dmitry V. Levin]

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

On Tue, Jul 03, 2007 at 09:50:48PM +0400, Valery V. Inozemtsev wrote:
> <skip>
> > > Если патч нужно обновить, то его нужно обновить.
> > > Не надо одним коммитом обновлять разные патчи по частям.
> >
> > Вот... в общем нужно нормальное руководство по всему этому хозяйству.. а
> > не архивы списков рассылки.
> 
> я об этом с самого начала говорил

Сначала коллективное знание будет в архивах списков рассылки, потом
кто-нибудь вызовется (или мы кого-нибудь попросим) привести это знание
к более удобному для постижения виде.
Наоборот не получится.  C'est la vie.

Так что продолжайте задавать вопросы и высказывать свои соображения.

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

Валера, это проще чем xorg собирать.


-- 
ldv

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

Re: [devel] srpms -> gear

[Valery V. Inozemtsev]

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

В сообщении от 3 июля 2007 Dmitry V. Levin написал(a):
> On Tue, Jul 03, 2007 at 09:50:48PM +0400, Valery V. Inozemtsev wrote:
> > <skip>
> >
> > > > Если патч нужно обновить, то его нужно обновить.
> > > > Не надо одним коммитом обновлять разные патчи по частям.
> > >
> > > Вот... в общем нужно нормальное руководство по всему этому хозяйству..
> > > а не архивы списков рассылки.
> >
> > я об этом с самого начала говорил
>
> Сначала коллективное знание будет в архивах списков рассылки, потом
> кто-нибудь вызовется (или мы кого-нибудь попросим) привести это знание
> к более удобному для постижения виде.
> Наоборот не получится.  C'est la vie.

все это я конечно понимаю...

>
> Так что продолжайте задавать вопросы и высказывать свои соображения.
>
> > > Мне теперь немного стало понятнее,
> >
> > а вот у меня нет времени разбираться, ковыряясь в рассылках, да и не буду
> > я этим заниматься... вот когда будет "нормальное руководство по всему
> > этому хозяйству", тогда я и буду смотреть в сторону alt.git, а пока как
> > то сподручнее по старинке
>
> Валера, это проще чем xorg собирать.

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

-- 
Valery V. Inozemtsev

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] srpms -> gear

[Michael Shigorin]

PreScriptum: это письмо является лоскутным и отчасти
просится в smoke-room@.

On Tue, Jul 03, 2007 at 01:28:36PM +0400, Dmitry V. Levin wrote:
> > У меня пока привыкание остановилось на подходе к apache и
> > xmms (2 solo: помню, но ещё всё так же не смотрел -- видимо,
> > уже на кофнференции).  Поскольку патчи из разных мест,
> > которые поддерживаю не я, пока возможней поддерживать со
> > старым добрым src.rpm, чем в гите.  Проблема в том, что эти
> > два апстрима, мягко говоря, консервативные и продавить их
> > туда уже не особо реально.
> gear-репозиторий, который получается на выходе gear-srpmimport,
> ни чуть не сложнее srpm-пакета, верно?

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

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

Поэтому изредка пользуюсь самыми элементарными вещами,
к которым уже успел привыкнуть или приспособиться, не больше.

> > > Видимого смысла в srpm-паетах после миграции на
> > > gear-репозитории не будет.
> > Было бы всё-таки хорошо иметь какой-то простой вариант
> > понять, чем отличается пакет от upstream tarball.  Причём не
> > глазами разработчика (им проще), а скорее глазами опытного
> > админа.
> gitweb?

Неочевидно, http://sisyphus.ru/srpm/xmms/patches намного
юзабельней. (из cvs.pld-linux.org тоже патчи выковыривать очень
неудобно, но они используют CVS где-то как rider@ упоминал:
хранилище, не более)

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

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

Вовсе не каждый человек, который может быть очень полезен ALT
Linux как проекту, должен быть или стать разработчиком в плане
понимания кода на C и нюансов autotools или вот git.

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

> Если нет, то как ты предлагаешь моделировать их нужды?

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

taf@, dlebkov@ или force@ -- весьма уважаемые мной скорее админы,
чем разработчики.  Просто сильно подозреваю, что как админы они
тоже эффективней, чем как разработчики.

> > Сейчас как минимум то, что твой репозиторий для получения
> > списка пакетов обрабатывается в среднем ближе к минуте --
> > тоже не помогает знакомиться с наработками.
> Зачем человеку может срочно понадобится список всех моих
> пакетов?  Я сам на него стараюсь не смотреть. :)

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

> P.S. Почему gitweb на этой операции так сильно тормозит?

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

Свежий пример приводится в конце письма.

> > Бишь даже с имеющимися концептуально крутыми инструментами
> > есть досадные практические проблемы вроде отсутствия
> > кэширования дорогих по времени получения результатов в
> > gitweb.
> todo++; чем лучше кэшировать?

Мож mithraen@ или at@ расскажут, чем из имеющихся кэширующих
прослоек на перле лучше пользоваться.  Я точно знаю, что эта
проблема свойственна многим веб-проектам и при растягивании
их на масштабируемость её приходится решать.

Очень приблизительно -- "слепить html-страничку и если даты
модификации чего-то, например каталогов, не моложе времени 
генерации -- отдавать её до устаревания".

Ещё может иметь смысл нарисовать на gitweb robots.txt и/или
зарегистрировать в Google Webmaster Tools и сказать лазить
пореже, если в access_log большая доля роботов.

Если там до сих пор нет nginx фронтэндом (reverse proxy)
-- очень рекомендую, можешь уточнить у lakostis@ эффект.
У меня схожий наблюдается.

-------------------------------------------------------------

Ммм... если это был i965 с добавочным контроллером JMicron, тогда
понятно (в ALT 4.0 Server вроде победили, но пока сам не
проверял).  Эти ж-микроны -- действительно гадость редкая.

А вот на GA-M55PLUS-S3G вчера помимо обычной работы проводили
стресс-тест, машинка достойно выдержала.  Он был такой:

- имеется эта мамка, X2 4400+ на ней, 4G DDR2-667, 2+2 SATA-диска
  и 1 SCSI
- установлен ALT 4.0 Server (ядро 2.6.18 с поддержкой OpenVZ)
- в одном VPS запущен офисный терминальный сервер, на нём пять
  клиентов болтаются
- в другом VPS -- 32-битная сборочница
- в третьем -- 64-битная сборочница
- и ещё с полдюжины контейнеров, которые особо не отсвечивают

Раньше сборка проводилась на SCSI, но пакеты для формирования
build chroot (довольно тяжёлая операция в плане I/O) брались с
тех же двух SATA-дисков, на которых в RAID1 живёт LTSP5.  А тут
"I" для сборочниц вынесли на отдельные два шпинделя.  В общем,
если на одном диске (на рабочей станции с гигом памяти и быстрым
процессором) такие три сборки параллельно запустить -- можно
вешаться, всё будет ползать.  Здесь же полностью развели
ввод-вывод и при офигенной загрузке на терминалах можно было
просто работать.  Ну опенофис запускается не две секунды, а 15,
если не из кэша (будучи один раз запущен -- опять за две
взлетает).  Ну подкрутили приоритеты, выдали терминал-серверу на
порядок большую долю процессорного времени и вообще незаметно,
что там за стенкой всё колбасится. :) 

-------------------------------------------------------------

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

Re: [devel] srpms -> gear

[Michael Shigorin]

PreScriptum: дайджест по треду.

On Tue, Jul 03, 2007 at 02:21:44PM +0400, Aleksey Novodvorsky wrote:
> > > Давайте отделять мух от котлет. Здесь нет никого,
> > > заинтересованного в сокрытии исходников. Наоборот.  Но
> > > форма предоставлени исходников может меняться. Важно, чтобы
> > > она была удобной, а не такой же, как всегда.

Да не в сокрытии исходников вопрос, а в практичной доступности
изменений.

Опять же по моей мерке -- дистрибутивы различаются качеством
сборки пакетов [в т.ч. патчами/интеграцией], апдейтами и
сообществом.  Последнее оценивается только субъективно,
второе -- скорее объективно, а вот первое -- смесью того 
и другого.

Например, netch@ был явно впечатлён, почитав патчи к альтовской
glibc при подготовке одного из курсов.  Не уверен, что он стал
бы читать git.  Хотя можно и спросить.

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

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

Кукбук нужен вроде "Everyday GIT".  Хотя бы по тому, что уже есть.
Готов пойти в подопытные кролики :)


On Tue, Jul 03, 2007 at 06:38:37PM +0400, Dmitry V. Levin wrote:
> > Я кстати согласен с Майк'ом - очень хочется иметь возможность
> > получить один или несколько патчей по сравнению с mainstream.
> Это тривиально, если соблюдается простое правило "один коммит
> не содержит логически несвязанных патчей"; в противном случае
> есть риск получить удовольствие собирать патч по разным
> коммитам, в которых находятся по несколько кусков логически
> несвязанных патчей.

Как обновить патч? (рекомендации, какие видел -- "откати в том
бранче старый патч и накати новый" -- больше похожи на увеличение
количества ручного труда, чем наоборот; хотя если бранчи строго
по патчам, то это вроде как --reset HEAD^, нет?)


On Tue, Jul 03, 2007 at 10:06:17PM +0400, Dmitry V. Levin wrote:
> > > > Если патч нужно обновить, то его нужно обновить.
> > > > Не надо одним коммитом обновлять разные патчи по частям.
> > > Вот... в общем нужно нормальное руководство по всему этому
> > > хозяйству.. а не архивы списков рассылки.
> > я об этом с самого начала говорил
> Сначала коллективное знание будет в архивах списков рассылки,
> потом кто-нибудь вызовется (или мы кого-нибудь попросим)
> привести это знание к более удобному для постижения виде.
> Наоборот не получится.  C'est la vie.  Так что продолжайте
> задавать вопросы и высказывать свои соображения.

Этому кому-то с радостью передам (немало пополнившийся из этого
треда) =packages/gear и заодно =packages/git.

> Валера, это проще чем xorg собирать.

xorg собирать (или истребитель водить) может быть привычней.


On Tue, Jul 03, 2007 at 02:40:55PM +0400, Dmitry V. Levin wrote:
> > > Давайте отделять мух от котлет.
> > я пока не вижу удобного способа "отделить котлеты от мух" в
> > git-репозитариях, а именно - получить тарболл и патчи к
> > пакету из репозитария.
> Разные gear-репозитории устроены по-разному, поскольку
> практически ничего не мешает мантейнерам организовать свои
> репозитории так как им удобно.

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

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


On Tue, Jul 03, 2007 at 03:11:33PM +0400, Dmitry V. Levin wrote:
> > Я давно уже зарёкся "выковыривать" что-либо из чьего-то
> > git-репозитария: лично мне на практике проще взять
> > оригинальный tarball от разработчика, или даже
> > за-checkout'ить CVS/SVN и заново пропатчить. Хотя, возможно,
> > я просто туплю...
> Давайте попробуем смоделировать ситуацию на конкретном примере,
> на ваш выбор.

Ну вот человек на опеннете пришёл с конкретно zsh и выяснил,
какой из патчей вызывал проблему.  Как выяснил -- я так и не
понял пока, наверное, из старого src.rpm.

> > а, возможно, потому, что "Разные gear-репозитории устроены
> > ПО-РАЗНОМУ, поскольку практически НИЧЕГО НЕ МЕШАЕТ не мешает
> > мантейнерам организовать свои репозитории так как ИМ удобно".
> На практике при всём потенциальном многообразии выделяется три
> основных типа устройства репозитория, см. EXAMPLES в
> gear-rules(5):

Спасибо!

> http://git.altlinux.org/people/ldv/packages/?p=gear.git;a=blob_plain;f=gear-rules.5.html;hb=html

http://git.altlinux.org/people/ldv/packages/gear.git/gear-rules.5.html
получается сделать или излишне?


On Tue, Jul 03, 2007 at 03:11:52PM +0400, Денис Смирнов wrote:
> Для разработчика проблем с git нет никаких, если он соизволил
> научиться им пользоваться.

If.

> Реальная проблема другая -- нужен инструмент не для
> разработчиков в team, а для тех кто со стороны хочет
> подсмотреть/утащить к себе патчи, тем самым убедившись
> в грамотности сборки у нас.

Приходим к тому, что есть "проблема представления", которую может
иметь смысл решать не именно на git.altlinux.org, а возможно и на
вторичном ресурсе вроде sisyphus.ru.


On Tue, Jul 03, 2007 at 08:59:18PM +0400, Dmitry V. Levin wrote:
> Так что если прикладывать патч не на скорую руку, то надо
> завести для патча бранч, закоммитить туда, а потом сделать git
> pull.

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


On Tue, Jul 03, 2007 at 02:59:47PM +0400, Денис Смирнов wrote:
> Как я уже не раз говорил -- тебе это только кажется. Если ты
> действительно _хочешь_ перенести в git, то просто натрави на
> эти пакет gear-srpmimport.  И с получившимся результатом
> работай так, как будто ты работаешь без всякого git.

Несколько мелких фенечек вроде alterator-laserjet, которые я
делал и которые не содержат патчей -- именно так и были втянуты
и поддерживаются ещё с той осени.

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

У меня и так сегодня работает ;)  Проблемы бывали -- например,
ненароком один src.rpm накрыл файлики из другого (наступал при
сборке apache для updates и backports в одном vserver'е, один
раз заметил, минимум один -- нет).  Зачем мне SCM, понимаю.

> >> Видимого смысла в srpm-паетах после миграции на
> >> gear-репозитории не будет.
> MS> Было бы всё-таки хорошо иметь какой-то простой вариант понять,
> MS> чем отличается пакет от upstream tarball.  Причём не глазами
> MS> разработчика (им проще), а скорее глазами опытного админа.
> В случае с приведенной выше "тупой" сборкой -- это видно
> невооруженным взглядом. А вот если используются особенности
> git, то да, для этого нужен какой-то инструмент.

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

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

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


On Tue, Jul 03, 2007 at 08:41:58PM +0400, Dmitry V. Levin wrote:
> > Пример: http://git.altlinux.org/people/ldv/packages/?p=file.git
> Добавил ещё одно правило для http-сервера, теперь можно
> использовать более естественные адреса, например:
> http://git.altlinux.org/people/ldv/packages/file.git

Только хотел спросить, а не руками ли то было набрано :)
Спасибо.

Ещё бы https://bugzilla.altlinux.org/bugid сделать:
http://www.bugzilla.org/docs/2.16/html/rewrite.html

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

Re: [devel] gear vs patches

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

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

On Tue, Jul 03, 2007 at 06:35:49PM +0400, Anton Farygin wrote:

AF> Пока не будет понятен механизм действия при выходе новой версии - это 
AF> unreal.
AF> Вот есть у меня текущий ImageMagick, вышла новая версия. Мои действия ? 
AF> (я не беру ImageMagick из их CVS, а скачиваю тарболл).

Тупо распаковать его в этот каталог, git add, git commit. Дальше обновлять
патчи вручную, ровно так же как ты это делаешь сейчас.


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

http://freesource.info
----------------------------------------------------------------------------
Ну, товарищи, я и такой и есть, гм.. академичный, с лёгким надутием щёк.
		-- kirill in docs@

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

Re: [devel] srpms -> gear

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

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

On Tue, Jul 03, 2007 at 10:40:11PM +0300, Michael Shigorin wrote:

MS> Мож mithraen@ или at@ расскажут, чем из имеющихся кэширующих
MS> прослоек на перле лучше пользоваться.  Я точно знаю, что эта
MS> проблема свойственна многим веб-проектам и при растягивании
MS> их на масштабируемость её приходится решать.

Для начала посмотреть что он там делает, и генерировать дисковый кэш.
Например perldoc DB.

Этап 2 -- web-часть таки сделать FastCGI, чтобы не перезапускать скрипт на
каждый чих (perl поднимается долго и нудно), если это ещё не сделано.

Этап 3 -- perldoc Memoize

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

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

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

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

http://freesource.info
----------------------------------------------------------------------------
ЗАКОН ШРЕДЕРА
 Нерешительность - основа гибкости.

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

Re: [devel] srpms -> gear

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

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

On Tue, Jul 03, 2007 at 11:18:40PM +0300, Michael Shigorin wrote:

MS> Например, netch@ был явно впечатлён, почитав патчи к альтовской
MS> glibc при подготовке одного из курсов.  Не уверен, что он стал
MS> бы читать git.  Хотя можно и спросить.

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

MS> Как обновить патч? (рекомендации, какие видел -- "откати в том
MS> бранче старый патч и накати новый" -- больше похожи на увеличение
MS> количества ручного труда, чем наоборот; хотя если бранчи строго
MS> по патчам, то это вроде как --reset HEAD^, нет?)

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

А возможность работать даже в таком состоянии, это существенный критерий
usability :)

MS> Приходим к тому, что есть "проблема представления", которую может
MS> иметь смысл решать не именно на git.altlinux.org, а возможно и на
MS> вторичном ресурсе вроде sisyphus.ru.

sisyphus.ru это вообще больная мозоль. Этот ресурс требует столь массивной
переделки, что она тянет на rewrite. Я подозреваю что если у тебя
выпросить весь список предлагаемых улучшений, то счет пойдет на десятки.

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

Дело в том, что git очень универсален. А мантейнер это такой нехороший
человек, который таки будет работать так, как _ему_ удобнее. И он
абсолютно в этом прав.

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

>> Да, ты не получишь преимуществ git, и у тебя патчи будут лежать
>> файликами.  Но это будет работать уже сегодня.  Глянь на мой
>> репозиторий с ppp. Там та же самая ситуация.
MS> У меня и так сегодня работает ;)  Проблемы бывали -- например,
MS> ненароком один src.rpm накрыл файлики из другого (наступал при
MS> сборке apache для updates и backports в одном vserver'е, один
MS> раз заметил, минимум один -- нет).  Зачем мне SCM, понимаю.

Вот. А работать ты можешь сейчас с git вообще сделав вид что ты не знаешь
таких страшных слов как "бранч". По крайней мере это даст тебе результат
уже сегодня. 

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

Поверь мне на слово, то что ты получишь натравив gear-srpmimport на apache
будет мало отличаться по удобству от srpm. Но зато ты получишь надежность
и все преимущества SCM относительно пакета в целом (увы, пока не освоишь
фигуры высшего пилотажа -- не относительно отдельных патчей).

Я до сих пор использую git весьма тупым образом. Но это работает.

MS> git действительно заточен скорее на оперативный merge патчей
MS> как минимум в рамках своей ветки (и между ветками).  Хорошая
MS> цель и хорошо, если для ядра оно работает, но в жизни попадаются
MS> и совсем другие ситуации.
MS> У админа mindset другой, для него патч вполне может быть
MS> непрозрачным.  Этакая штука, которую если прилепить -- с этим
MS> полегчает или то починится.  Ему не надо ничего мержить, ему
MS> чтоб работало.

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

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

http://freesource.info
----------------------------------------------------------------------------
АФОРИЗМ МАТЦА
 Вывод - то место в тексте, где вы устали думать.

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

Re: [devel] srpms -> gear

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

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

On Tue, Jul 03, 2007 at 09:45:47PM +0400, Anton Farygin wrote:

AF> Мне теперь немного стало понятнее, но всё равно есть проблема - дорогой 
AF> трафик. Качать например git ядра - 100 с лишним метров..

Некоторые сторонники класть tar'ы не распакованые резко увеличивают тем
самым объем своего репо.

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

http://freesource.info
----------------------------------------------------------------------------
Так это был вопрос, ответ или философское размышление в двух лицах?
		-- mike in #5066

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

Re: [devel] srpms -> gear : патчи и бранчи

[Eugene Prokopiev]

>>Так что если прикладывать патч не на скорую руку, то надо
>>завести для патча бранч, закоммитить туда, а потом сделать git
>>pull.
> 
> 
> Вот это бы тоже как-то автоматизировать, чтоб ненароком не
> засунуть в уже существующий бранч или ещё чего.  Кто так делает
> -- там есть типичная последовательность действий или не особо?

Можно я вмешаюсь и расскажу, как я делаю?

Задача: исправить чего-нибудь в исходниках, чтоб работало как мне надо. 
Условие: есть только один сервер и он ну почти продакшн или готовится к 
нему.

Что делаю: инициализирую каталог для hasher на этом сервере, ставлю в 
него все необходимое для сборки + собираемый пакет, после hsh-shell 
собираю его с помощью rpm -bb, иду в BUILD, правлю по вкусу, откладывая 
оригиналы в сторонку, делаю make. Получившиеся бинарники копирую в живую 
систему, тестирую, как правило, с первого раза не выходит, повторяю 
процесс, пока не получится. Когда получилось, делаю diff, его уже тащу к 
себе на сборочный виртуальный сервер с гитом, на котором держу свои 
репозитарии, там этот патч обычным образом прикладываю без всяких 
бранчей и собираю новую версию пакета.

Теперь скажите мне, я правда облегчу себе жизнь, заморачиваясь с 
бранчами? Можно по шагам смоделировать эту ситуацию (которая, как мне 
кажется, не одного меня должна касаться) но уже более правильным 
образом? И лучше даже не сейчас, а на конференции/фесте?

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

Re: [devel] srpms -> gear

[Anton Farygin]

Денис Смирнов wrote:
> On Tue, Jul 03, 2007 at 09:45:47PM +0400, Anton Farygin wrote:
> 
> AF> Мне теперь немного стало понятнее, но всё равно есть проблема - дорогой 
> AF> трафик. Качать например git ядра - 100 с лишним метров..
> 
> Некоторые сторонники класть tar'ы не распакованые резко увеличивают тем
> самым объем своего репо.

Если кладётся tar не сжатый, то вообще-то git делает дельту.

Re: [devel] srpms -> gear

[Kirill A. Shutemov]

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

On [Wed, 04.07.2007 11:05], Anton Farygin wrote:
> Денис Смирнов wrote:
> > On Tue, Jul 03, 2007 at 09:45:47PM +0400, Anton Farygin wrote:
> > 
> > AF> Мне теперь немного стало понятнее, но всё равно есть проблема - дорогой 
> > AF> трафик. Качать например git ядра - 100 с лишним метров..
> > 
> > Некоторые сторонники класть tar'ы не распакованые резко увеличивают тем
> > самым объем своего репо.
> 
> Если кладётся tar не сжатый, то вообще-то git делает дельту.
Всё равно размер репозитория становиться значительно больши. Проверено
эксперементальным путём.

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

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + Velesys LLC, http://www.velesys.com/
 + ALT Linux Team, http://www.altlinux.com/

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

Re: [devel] srpms -> gear

[Michael Shigorin]

On Wed, Jul 04, 2007 at 01:40:37AM +0400, Денис Смирнов wrote:
> sisyphus.ru это вообще больная мозоль. Этот ресурс требует
> столь массивной переделки, что она тянет на rewrite. Я
> подозреваю что если у тебя выпросить весь список предлагаемых
> улучшений, то счет пойдет на десятки.

Да тут и выпрашивать не надо, в основном всё в bugzilla на
prometeus из Sisyphus, а архив переписки и соображений выдаётся
по требованию.

> MS> У меня и так сегодня работает ;)  Проблемы бывали -- например,
> MS> ненароком один src.rpm накрыл файлики из другого (наступал при
> MS> сборке apache для updates и backports в одном vserver'е, один
> MS> раз заметил, минимум один -- нет).  Зачем мне SCM, понимаю.
> Вот. А работать ты можешь сейчас с git вообще сделав вид что ты
> не знаешь таких страшных слов как "бранч". По крайней мере это
> даст тебе результат уже сегодня. 

Пока это давало ещё и лишний расход времени, который не давал
толку больше, чем архив SRPMS.

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

Эй.  Если ты не заметил, я как раз не хочу "купить истребитель
и сразу".  А интересуюсь, и что вышло у купивших, или пока только
полубочки не отрываясь от ВПП.

> Поверь мне на слово, то что ты получишь натравив
> gear-srpmimport на apache будет мало отличаться по удобству от
> srpm.

Поверь и ты мне на слово, уже проверено для пакетов попроще.

> Я до сих пор использую git весьма тупым образом. Но это работает.

Мож ещё подход сделаю, но лучше сперва посмотрю вас с Димой 
в Обнинске. :)

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

Re: [devel] srpms -> gear

[Michael Shigorin]

On Wed, Jul 04, 2007 at 11:20:01AM +0300, Kirill A. Shutemov wrote:
> > > Некоторые сторонники класть tar'ы не распакованые резко
> > > увеличивают тем самым объем своего репо.
> > Если кладётся tar не сжатый, то вообще-то git делает дельту.
> Всё равно размер репозитория становиться значительно больши.
> Проверено эксперементальным путём.  А чем вам не угадил
> распакованый тарбол?

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

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

Re: [devel] srpms -> gear

[Kirill A. Shutemov]

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

On [Wed, 04.07.2007 13:00], Michael Shigorin wrote:
> On Wed, Jul 04, 2007 at 11:20:01AM +0300, Kirill A. Shutemov wrote:
> > > > Некоторые сторонники класть tar'ы не распакованые резко
> > > > увеличивают тем самым объем своего репо.
> > > Если кладётся tar не сжатый, то вообще-то git делает дельту.
> > Всё равно размер репозитория становиться значительно больши.
> > Проверено эксперементальным путём.  А чем вам не угадил
> > распакованый тарбол?
> 
> Мужуки, на всякий предупреждаю: вы об одном и том же, поскольку
> "нераспакованный тарбол" -- антоним "несжатого тарбола".

Под нераспакованым тарболом я понимал то, что увидел тут -
http://git.altlinux.org/people/thresh/packages/ocaml.git?p=ocaml.git;a=tree

то есть .tar лежащий в git.

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + Velesys LLC, http://www.velesys.com/
 + ALT Linux Team, http://www.altlinux.com/

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

Re: [devel] gear vs patches

[Kirill A. Shutemov]

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

On [Tue, 03.07.2007 20:41], Dmitry V. Levin wrote:
> On Tue, Jul 03, 2007 at 07:00:00PM +0400, Dmitry V. Levin wrote:
> > On Tue, Jul 03, 2007 at 06:35:49PM +0400, Anton Farygin wrote:
> > [...]
> > > Вот есть у меня текущий ImageMagick, вышла новая версия. Мои действия ? 
> > > (я не беру ImageMagick из их CVS, а скачиваю тарболл).
> > 
> > В зависимости от того, как устроен gear-репозиторий,
> > есть 2 проработанных варианта обновления из тарболлов:
> > 
> > 1. В репозитории все изменения оформлены в виде отдельных патчей,
> > upstream'ный исходный код хранится _без_ изменений, каждый тарболл развёрнут
> > в индивидуальном подкаталоге (такую схему использует gear-srpmimport).
> > Тогда с помощью утилиты gear-update(1) можно обновлять подкаталоги из
> > тарболлов.
> > Пример: http://git.altlinux.org/people/ldv/packages/?p=gcc4.1.git
> > 
> > 2. В репозитории есть изменения, которые приложены, т.е. есть подкаталоги,
> > которые содержат upstream'ный исходный код _с_ изменениями.
> > Тогда каждый такой каталог следует поместить в отдельный бранч для того,
> > чтобы хранить исходный код без изменений отдельно, обновлять его с
> > помощью gear-update(1) по первому варианту.  С помощью "git pull"
> > обновления с этих бранчей по мере надобности вливаются в основной бранч.
> > Пример: http://git.altlinux.org/people/ldv/packages/?p=file.git
> 
> Добавил ещё одно правило для http-сервера, теперь можно использовать более
> естественные адреса, например:
> http://git.altlinux.org/people/ldv/packages/file.git

А ещё и без .git в конце можно? git уже в имени хоста есть.

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + Velesys LLC, http://www.velesys.com/
 + ALT Linux Team, http://www.altlinux.com/

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

Re: [devel] srpms -> gear

[Anton Farygin]

Kirill A. Shutemov wrote:
> On [Wed, 04.07.2007 11:05], Anton Farygin wrote:
>> Денис Смирнов wrote:
>>> On Tue, Jul 03, 2007 at 09:45:47PM +0400, Anton Farygin wrote:
>>>
>>> AF> Мне теперь немного стало понятнее, но всё равно есть проблема - дорогой 
>>> AF> трафик. Качать например git ядра - 100 с лишним метров..
>>>
>>> Некоторые сторонники класть tar'ы не распакованые резко увеличивают тем
>>> самым объем своего репо.
>> Если кладётся tar не сжатый, то вообще-то git делает дельту.
> Всё равно размер репозитория становиться значительно больши. Проверено
> эксперементальным путём.
> 
> А чем вам не угадил распакованый тарбол?

Лишние итерации.. меня устраивает то что есть сейчас.

Re: [devel] srpms -> gear

[Kirill A. Shutemov]

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

On [Wed, 04.07.2007 15:54], Anton Farygin wrote:
> Kirill A. Shutemov wrote:
> > On [Wed, 04.07.2007 11:05], Anton Farygin wrote:
> >> Денис Смирнов wrote:
> >>> On Tue, Jul 03, 2007 at 09:45:47PM +0400, Anton Farygin wrote:
> >>>
> >>> AF> Мне теперь немного стало понятнее, но всё равно есть проблема - дорогой 
> >>> AF> трафик. Качать например git ядра - 100 с лишним метров..
> >>>
> >>> Некоторые сторонники класть tar'ы не распакованые резко увеличивают тем
> >>> самым объем своего репо.
> >> Если кладётся tar не сжатый, то вообще-то git делает дельту.
> > Всё равно размер репозитория становиться значительно больши. Проверено
> > эксперементальным путём.
> > 
> > А чем вам не угадил распакованый тарбол?
> 
> Лишние итерации.. меня устраивает то что есть сейчас.

Получаются совсем невменяемые между ревизиями diff'ы => нафик.

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + Velesys LLC, http://www.velesys.com/
 + ALT Linux Team, http://www.altlinux.com/

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

Re: [devel] srpms -> gear : патчи и бранчи

[Igor Zubkov]

В сообщении от Wednesday 04 July 2007 09:32:41 Eugene Prokopiev написал(а):
> Что делаю: инициализирую каталог для hasher на этом сервере, ставлю в
> него все необходимое для сборки + собираемый пакет, после hsh-shell
> собираю его с помощью rpm -bb, иду в BUILD, правлю по вкусу, откладывая
> оригиналы в сторонку, делаю make. Получившиеся бинарники копирую в живую
> систему, тестирую, как правило, с первого раза не выходит, повторяю
> процесс, пока не получится. Когда получилось, делаю diff, его уже тащу к
> себе на сборочный виртуальный сервер с гитом, на котором держу свои
> репозитарии, там этот патч обычным образом прикладываю без всяких
> бранчей и собираю новую версию пакета.

А вот тут поподробней.
1) эти исправления отправлены в upstream?
2) как другие могут вытащить отдельные патчи? т.е. по патчу на одну проблему?

-- 
icesik

Re: [devel] srpms -> gear

[Igor Zubkov]

В сообщении от Tuesday 03 July 2007 23:18:40 Michael Shigorin написал(а):
> PreScriptum: дайджест по треду.
>
> On Tue, Jul 03, 2007 at 02:21:44PM +0400, Aleksey Novodvorsky wrote:
> > > > Давайте отделять мух от котлет. Здесь нет никого,
> > > > заинтересованного в сокрытии исходников. Наоборот.  Но
> > > > форма предоставлени исходников может меняться. Важно, чтобы
> > > > она была удобной, а не такой же, как всегда.
>
> Да не в сокрытии исходников вопрос, а в практичной доступности
> изменений.

Попробую добавить свои пять копеек в этот тред.

Начнём с того что я недавно решил поковырять pulseaudio. Я полез, скопировал с 
git.altlinux.org pulseaudio.git и решил посмотреть что и где. Мне от туда 
надо было найти два патча и приложить их в своей сборке для Дедала (кстати, я 
её сегодня выкачу). Моя долго ругатся. Пока я нашёл эти два пачта в более чем 
сотни коммитов, я думал я вспомню весь матерный который я знаю. В этот день 
все на офисе слышали как я матерился. Ладно, с горем пополам, я вытащил эти 
патчи. Как оказалось они не накладываются. Уж не знаю, то ли я их криво 
экспортнул, то ли код действительно поехал. Пришлось делать их заново. 
Сдедал. Сейчас проверю пакет и оправлю в Дедал.

Мораль:
Патченные тарболы зло. Я выковырял патчи т.к. я хоть чучуть знаю как у нас это 
всё устроено. А как быть человеку который не знает? В копилку, ещё одие 
момент. Похожую схему с патчеными тарболами используют в debian. Только у них 
лежит оригинальный тарбол и большой патч для дебианизации. Ещё три (или 
четыре) года назад во времена woody в этом большом патче для дебианизации 
лежали патчи, а сейчас этого нет. Ленивый стал народ. В итоге, таскать что ли 
из debian становится просто не выносимо тяжело. Попробуй вытащить из этого 
большого патча то что тебе нужно. Мне это очень сильно напрягает в debian. И 
получается что мы сейчас перенимает из debian тоже свойство. Не самое лучшее. 
А git.alt это ещё и усиляет.

Ну и по поводу git.alt. Пока я в нём вижу для себя только минусы, чем плюсы. 
Отсутствие документации. (огрызки на вики я не считаю за документацию). 
Теряется поняниет патч{,и}. Поднимается уровень вхождения в команду. Нас и 
так мало, а от таких вещей нас больше не станет.

p.s.: ну и я пока постою в сторонке с git.alt.

> Опять же по моей мерке -- дистрибутивы различаются качеством
> сборки пакетов [в т.ч. патчами/интеграцией], апдейтами и
> сообществом.  Последнее оценивается только субъективно,
> второе -- скорее объективно, а вот первое -- смесью того
> и другого.

С security обновлениями у нас не сильно хорошо. Это факт.

> On Tue, Jul 03, 2007 at 06:38:37PM +0400, Dmitry V. Levin wrote:
> > > Я кстати согласен с Майк'ом - очень хочется иметь возможность
> > > получить один или несколько патчей по сравнению с mainstream.
> >
> > Это тривиально, если соблюдается простое правило "один коммит
> > не содержит логически несвязанных патчей"; в противном случае
> > есть риск получить удовольствие собирать патч по разным
> > коммитам, в которых находятся по несколько кусков логически
> > несвязанных патчей.
>
> Как обновить патч? (рекомендации, какие видел -- "откати в том
> бранче старый патч и накати новый" -- больше похожи на увеличение
> количества ручного труда, чем наоборот; хотя если бранчи строго
> по патчам, то это вроде как --reset HEAD^, нет?)

Вот тут получает что нужно хорошее знание SCM. Я таким погордится не могу. Да 
и большинство наверно тоже. (или я слишком утрирую?)

> > Валера, это проще чем xorg собирать.
>
> xorg собирать (или истребитель водить) может быть привычней.

А мне вот удобнее собирать пакеты без hasher в живой системе. Это так, к 
слову. Меня это не смущает. Да и большинство моих пакетов вполне себе 
работает.

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

:)

> On Tue, Jul 03, 2007 at 03:11:33PM +0400, Dmitry V. Levin wrote:
> > > Я давно уже зарёкся "выковыривать" что-либо из чьего-то
> > > git-репозитария: лично мне на практике проще взять
> > > оригинальный tarball от разработчика, или даже
> > > за-checkout'ить CVS/SVN и заново пропатчить. Хотя, возможно,
> > > я просто туплю...
> >
> > Давайте попробуем смоделировать ситуацию на конкретном примере,
> > на ваш выбор.
>
> Ну вот человек на опеннете пришёл с конкретно zsh и выяснил,
> какой из патчей вызывал проблему.  Как выяснил -- я так и не
> понял пока, наверное, из старого src.rpm.

Вот примерно тоже у меня.

> У админа mindset другой, для него патч вполне может быть
> непрозрачным.  Этакая штука, которую если прилепить -- с этим
> полегчает или то починится.  Ему не надо ничего мержить, ему
> чтоб работало.

+1

> Ещё бы https://bugzilla.altlinux.org/bugid сделать:
> http://www.bugzilla.org/docs/2.16/html/rewrite.html

Было бы хорошо.

-- 
icesik

Re: [devel] srpms -> gear

[Igor Zubkov]

В сообщении от Wednesday 04 July 2007 00:40:37 Денис Смирнов написал(а):
> Я не сторонник резких изменений. Миша, ты хочешь всю жизнь проходив пешком
> купить себе истребитель и сразу же начать делать фигуры высшего пилотажа.
> Потом в связи с тем что эти фигуры не получились сказать "фигня ваш
> истребитель, я буду пешком ходить". Может для начала просто начнешь
> применять его для ежедневных полетов на работу и обратно? ;)

Да-да. Не надо нас пинками в светлое будущее.

-- 
icesik

Re: [devel] srpms -> gear

[Michael Shigorin]

On Wed, Jul 04, 2007 at 04:46:53PM +0300, Igor Zubkov wrote:
> Начнём с того что я недавно решил поковырять pulseaudio. Я
> полез, скопировал с git.altlinux.org pulseaudio.git и решил
> посмотреть что и где.

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

mkdir ~/git
cd ~/git
git clone git.alt:/people/sbolshakov/packages/pulseaudio.git
cd pulseaudio
gitk

> Похожую схему с патчеными тарболами используют в debian. Только
> у них лежит оригинальный тарбол и большой патч для
> дебианизации. Ещё три (или четыре) года назад во времена woody
> в этом большом патче для дебианизации лежали патчи, а сейчас
> этого нет. Ленивый стал народ.

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

> Ну и по поводу git.alt. Пока я в нём вижу для себя только
> минусы, чем плюсы.  Отсутствие документации. (огрызки на вики я
> не считаю за документацию). 

Да, там лихорадочные и перекрученные разные темы, на руководство
никак не конают. (понимаю, что это и моя вина, но у меня-то тоже
понимания толком нет)

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

Re: [devel] srpms -> gear

[Igor Zubkov]

05.07.07, Michael Shigorin<mike@osdn.org.ua> написал(а):
> On Wed, Jul 04, 2007 at 04:46:53PM +0300, Igor Zubkov wrote:
> > Начнём с того что я недавно решил поковырять pulseaudio. Я
> > полез, скопировал с git.altlinux.org pulseaudio.git и решил
> > посмотреть что и где.
>
> Надеюсь, ты в курсе, как это делается, хоть в первом приближении?
>
> mkdir ~/git
> cd ~/git
> git clone git.alt:/people/sbolshakov/packages/pulseaudio.git
> cd pulseaudio
> gitk

Примерно так, только вместо gitk -- qgit. Именно им я и выдирал патчи.

> > Похожую схему с патчеными тарболами используют в debian. Только
> > у них лежит оригинальный тарбол и большой патч для
> > дебианизации. Ещё три (или четыре) года назад во времена woody
> > в этом большом патче для дебианизации лежали патчи, а сейчас
> > этого нет. Ленивый стал народ.
>
> Странно, мне казалось, наоборот -- будто процент встречающихся
> "разобранных" diff'ов у них повысился от скорее нулевого.

В те времена они встречали мне чаще чем сейчас. Вообще, эта штука с
патчами (когда один патч на одно действие) называется dpatch.
Осиливается на ура с пол пинка. Так что им не зачёт по этой части.
Главное что бы потом не говорили про нас такое же...

> > Ну и по поводу git.alt. Пока я в нём вижу для себя только
> > минусы, чем плюсы.  Отсутствие документации. (огрызки на вики я
> > не считаю за документацию).
>
> Да, там лихорадочные и перекрученные разные темы, на руководство
> никак не конают. (понимаю, что это и моя вина, но у меня-то тоже
> понимания толком нет)

Вот кратко и без души. Я сам не сильно понимаю:
http://www.freesource.info/wiki/AltLinux/Sisyphus/devel/gear/kiss?v=8e

-- 
icesik

Re: [devel] srpms -> gear : патчи и бранчи

[Eugene Prokopiev]

Igor Zubkov пишет:
> В сообщении от Wednesday 04 July 2007 09:32:41 Eugene Prokopiev написал(а):
> 
>>Что делаю: инициализирую каталог для hasher на этом сервере, ставлю в
>>него все необходимое для сборки + собираемый пакет, после hsh-shell
>>собираю его с помощью rpm -bb, иду в BUILD, правлю по вкусу, откладывая
>>оригиналы в сторонку, делаю make. Получившиеся бинарники копирую в живую
>>систему, тестирую, как правило, с первого раза не выходит, повторяю
>>процесс, пока не получится. Когда получилось, делаю diff, его уже тащу к
>>себе на сборочный виртуальный сервер с гитом, на котором держу свои
>>репозитарии, там этот патч обычным образом прикладываю без всяких
>>бранчей и собираю новую версию пакета.
> 
> 
> А вот тут поподробней.
> 1) эти исправления отправлены в upstream?

Зависит от апстрима. Если протолкнуть получается, в следующей сборке 
делаем git-rm file.patch ну и т.д. :)

> 2) как другие могут вытащить отдельные патчи? т.е. по патчу на одну проблему?

да

с точки зрения таскающего патчи ничего не меняется, о git знать ему не надо

патчи в моем гите - это именно отдельные файлы

т.е. я использую тот самый истребитель на конной тяге :)

преимущества от гита при таком подходе - всего лишь более удобное 
расположение файлов по сравнению с ~/RPM и бесплатный бэкап на 
git.altlinux.ru ;)

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

Re: [devel] srpms -> gear

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

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

On Wed, Jul 04, 2007 at 11:06:05AM +0400, Anton Farygin wrote:

> AF>> Мне теперь немного стало понятнее, но всё равно есть проблема - дорогой 
> AF>> трафик. Качать например git ядра - 100 с лишним метров..
>> Некоторые сторонники класть tar'ы не распакованые резко увеличивают тем
>> самым объем своего репо.
AF> Если кладётся tar не сжатый, то вообще-то git делает дельту.

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

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

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

http://freesource.info
----------------------------------------------------------------------------
> Так скоро анфриз сизифа?
Так вы не заметили?
Уже неделю как.
		-- ldv in devel@

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

Re: [devel] srpms -> gear

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

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

On Wed, Jul 04, 2007 at 12:59:09PM +0300, Michael Shigorin wrote:

>> Вот. А работать ты можешь сейчас с git вообще сделав вид что ты
>> не знаешь таких страшных слов как "бранч". По крайней мере это
>> даст тебе результат уже сегодня. 
MS> Пока это давало ещё и лишний расход времени, который не давал
MS> толку больше, чем архив SRPMS.

Ты хранишь у себя полный архив SRPMS? Ты крут, однако :) Я вот уже
несколько раз был спасен git-bisect, например. И архив SRPMS мне тут хоть
и мог бы помочь, да было бы это куда более трудоемким.

А ешё я всегда могу запустить tig и глянуть на изменения. Удобно.

>> Я не сторонник резких изменений. Миша, ты хочешь всю жизнь
>> проходив пешком купить себе истребитель и сразу же начать
>> делать фигуры высшего пилотажа.
MS> Эй.  Если ты не заметил, я как раз не хочу "купить истребитель
MS> и сразу".  А интересуюсь, и что вышло у купивших, или пока только
MS> полубочки не отрываясь от ВПП.

Хотя куда проще пока без всяких фигур высшего пилотажа просто летать себе
на работу и обратно :)

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

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

>> Поверь мне на слово, то что ты получишь натравив
>> gear-srpmimport на apache будет мало отличаться по удобству от
>> srpm.
MS> Поверь и ты мне на слово, уже проверено для пакетов попроще.
>> Я до сих пор использую git весьма тупым образом. Но это работает.
MS> Мож ещё подход сделаю, но лучше сперва посмотрю вас с Димой 
MS> в Обнинске. :)

Боюсь в Обнинске ты меня не увидишь. Если хочешь -- по SIP состыкуемся и
поболтаем online, зайдя ssh на одну машинку и ковыряясь вместе с git. Увы,
videoconferencing пока не отладил, но надеюсь нам и audio хватит :)

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

http://freesource.info
----------------------------------------------------------------------------
> в пакете отсутствует man для subst.
Может лучше плавно переходить на "sed -i"?
		-- ldv in #6571

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

Re: [devel] srpms -> gear : патчи и бранчи

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

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

On Thu, Jul 05, 2007 at 11:36:32AM +0400, Eugene Prokopiev wrote:

EP> с точки зрения таскающего патчи ничего не меняется, о git знать ему не надо
EP> патчи в моем гите - это именно отдельные файлы
EP> т.е. я использую тот самый истребитель на конной тяге :)
EP> преимущества от гита при таком подходе - всего лишь более удобное 
EP> расположение файлов по сравнению с ~/RPM и бесплатный бэкап на 
EP> git.altlinux.ru ;)

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

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

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

http://freesource.info
----------------------------------------------------------------------------
*** Bug 3334 has been marked as a duplicate of this bug. ***
		-- mouse in #4443

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

Re: [devel] srpms -> gear

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

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

On Wed, Jul 04, 2007 at 04:46:53PM +0300, Igor Zubkov wrote:

IZ> Начнём с того что я недавно решил поковырять pulseaudio. Я полез, скопировал с 
IZ> git.altlinux.org pulseaudio.git и решил посмотреть что и где. Мне от туда 
IZ> надо было найти два патча и приложить их в своей сборке для Дедала (кстати, я 
IZ> её сегодня выкачу). Моя долго ругатся. Пока я нашёл эти два пачта в более чем 
IZ> сотни коммитов, я думал я вспомню весь матерный который я знаю. В этот день 
IZ> все на офисе слышали как я матерился. Ладно, с горем пополам, я вытащил эти 
IZ> патчи. Как оказалось они не накладываются. Уж не знаю, то ли я их криво 
IZ> экспортнул, то ли код действительно поехал. Пришлось делать их заново. 
IZ> Сдедал. Сейчас проверю пакет и оправлю в Дедал.

Если там все патчи в master, то это обычно означает что где-то в отдельном
бранче лежит чистый upstream. git diff upstreambranchname выдаст тебе
разницу между этими бранчами. Остальное дело редактора.

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

IZ> Ну и по поводу git.alt. Пока я в нём вижу для себя только минусы, чем плюсы. 
IZ> Отсутствие документации. (огрызки на вики я не считаю за документацию). 
IZ> Теряется поняниет патч{,и}. Поднимается уровень вхождения в команду. Нас и 
IZ> так мало, а от таких вещей нас больше не станет.

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

Если конкретно -- те люди, которые сейчас работют над git.alt загружены
более чем на 100%, поэтому критика в общем-то сейчас бессмысленна. Если у
кого есть время и желание им помочь, думаю все скажут большое спасибо.

Нет доки? Ругаться все могут. А написать доку слабо? ldv@ вместе с vsu@
написали здесь столько ценнейших писем, что на их базе вполне можно
написать доку. Желающие есть? Вот-вот, и я о том же.

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

>> xorg собирать (или истребитель водить) может быть привычней.
IZ> А мне вот удобнее собирать пакеты без hasher в живой системе. Это так, к 
IZ> слову. Меня это не смущает. Да и большинство моих пакетов вполне себе 
IZ> работает.

При разработке пофиг как собирать, лишь бы то что идет в репо собиралось в
hasher'е. К счастью ни у кого кроме небольшого количества людей нету
способа залить в репо минуя хэшер, а те кто имеют такие возможности вряд
ли такое сделают :)

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

http://freesource.info
----------------------------------------------------------------------------
Некоторые вещи красивее оригинала не напишешь...
		-- lav in devel@

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

Re: [devel] srpms -> gear

[Dmitry V. Levin]

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

On Fri, Jul 06, 2007 at 05:17:44AM +0400, Денис Смирнов wrote:
> On Wed, Jul 04, 2007 at 11:06:05AM +0400, Anton Farygin wrote:
> 
> > AF>> Мне теперь немного стало понятнее, но всё равно есть проблема - дорогой 
> > AF>> трафик. Качать например git ядра - 100 с лишним метров..
> >> Некоторые сторонники класть tar'ы не распакованые резко увеличивают тем
> >> самым объем своего репо.
> AF> Если кладётся tar не сжатый, то вообще-то git делает дельту.
> 
> По факту от этой дельты проку ноль. Кроме того пользователь оказывается
> лишен возможности делать diff между сборками, чтобы посмотреть что в коде
> поменялось. Собственно все возможности по работе с кодом идут лесом.
> 
> От такого подхода масса вреда и никакой пользы. Если хочешь я лично для
> тебя напишу скриптик, который будет этот тарбол распаковывать.

Денис, этот скриптик называется gear-update(1).


-- 
ldv

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

Re: [devel] srpms -> gear

[Eugene Prokopiev]

>>От такого подхода масса вреда и никакой пользы. Если хочешь я лично для
>>тебя напишу скриптик, который будет этот тарбол распаковывать.
> 
> 
> Денис, этот скриптик называется gear-update(1).

http://lists.altlinux.org/pipermail/devel/2007-June/046974.html

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

Re: [devel] srpms -> gear

[Dmitry V. Levin]

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

On Fri, Jul 06, 2007 at 11:07:37AM +0400, Eugene Prokopiev wrote:
> >>От такого подхода масса вреда и никакой пользы. Если хочешь я лично для
> >>тебя напишу скриптик, который будет этот тарбол распаковывать.
> > 
> > 
> > Денис, этот скриптик называется gear-update(1).
> 
> http://lists.altlinux.org/pipermail/devel/2007-June/046974.html

Желательно сперва закоммитить свои изменения прежде чем начинать
обновление дерева.


-- 
ldv

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

Re: [devel] srpms -> gear

[Michael Shigorin]

On Fri, Jul 06, 2007 at 05:23:14AM +0400, Денис Смирнов wrote:
> >> Вот. А работать ты можешь сейчас с git вообще сделав вид что ты
> >> не знаешь таких страшных слов как "бранч". По крайней мере это
> >> даст тебе результат уже сегодня. 
> MS> Пока это давало ещё и лишний расход времени, который не давал
> MS> толку больше, чем архив SRPMS.
> Ты хранишь у себя полный архив SRPMS? Ты крут, однако :) Я вот
> уже несколько раз был спасен git-bisect, например. И архив
> SRPMS мне тут хоть и мог бы помочь, да было бы это куда более
> трудоемким.

Два года назад так и делалось, скрипт остался.  Можно опять
поднять, никакой крути :)

> Хотя куда проще пока без всяких фигур высшего пилотажа просто
> летать себе на работу и обратно :)

Я сейчас даже не езжу, а предпочитаю пешочком.

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

В т.ч.

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

Не собираюсь, навидался уже переразгребаний недовнедрений.

> Боюсь в Обнинске ты меня не увидишь.

Ну Диму увижу. :)

> Если хочешь -- по SIP состыкуемся и поболтаем online, зайдя ssh
> на одну машинку и ковыряясь вместе с git.

BTW screen вроде умеет такую "классную доску" организовывать.

Может, действительно по мере возможности изредка анонсировать
и устраивать уроки мастерства в рамках команды или sisyphus@?

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

Re: [devel] srpms -> gear

[Alexey Rusakov]

On Fri, 6 Jul 2007 20:09:48 +0300
Michael Shigorin wrote:

> On Fri, Jul 06, 2007 at 05:23:14AM +0400, Денис Смирнов wrote:
> > >> Вот. А работать ты можешь сейчас с git вообще сделав вид что ты
> > >> не знаешь таких страшных слов как "бранч". По крайней мере это
> > >> даст тебе результат уже сегодня. 
> > MS> Пока это давало ещё и лишний расход времени, который не давал
> > MS> толку больше, чем архив SRPMS.
> > Ты хранишь у себя полный архив SRPMS? Ты крут, однако :) Я вот
> > уже несколько раз был спасен git-bisect, например. И архив
> > SRPMS мне тут хоть и мог бы помочь, да было бы это куда более
> > трудоемким.
> 
> Два года назад так и делалось, скрипт остался.  Можно опять
> поднять, никакой крути :)
> 
> > Хотя куда проще пока без всяких фигур высшего пилотажа просто
> > летать себе на работу и обратно :)
> 
> Я сейчас даже не езжу, а предпочитаю пешочком.
> 
> > Ибо я готов поспорить, что ты до сих пор имеешь хоть какие-то
> > проблемы с git, потому как не имеешь времени, которое мог бы
> > выделить на то чтобы сесть и разобраться хорошенько.
> 
> В т.ч.
> 
> > А раз так -- до разберешься все равно только когда время будет.
> > А пока внедряй то, что умеешь уже сегодня.
> 
> Не собираюсь, навидался уже переразгребаний недовнедрений.
> 
> > Боюсь в Обнинске ты меня не увидишь.
> 
> Ну Диму увижу. :)
> 
> > Если хочешь -- по SIP состыкуемся и поболтаем online, зайдя ssh
> > на одну машинку и ковыряясь вместе с git.
> 
> BTW screen вроде умеет такую "классную доску" организовывать.
> 
> Может, действительно по мере возможности изредка анонсировать
> и устраивать уроки мастерства в рамках команды или sisyphus@?
Кстати да, я бы не отказался от таких "уроков" при условии наличия
интерактива. Я даже готов сам устраивать "курсы молодого бойца" по
собиранию пакетов и взаимодействию с апстримом время от времени, если будет
технология ведения таких "уроков". Не передний край, но для расширения
рядов тим, по-моему, было бы полезно.

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

[devel] [JT] ALT remote learning

[Michael Shigorin]

On Fri, Jul 06, 2007 at 09:34:19PM +0400, Alexey Rusakov wrote:
> > BTW screen вроде умеет такую "классную доску" организовывать.
> > Может, действительно по мере возможности изредка анонсировать
> > и устраивать уроки мастерства в рамках команды или sisyphus@?
> Кстати да, я бы не отказался от таких "уроков" при условии
> наличия интерактива. Я даже готов сам устраивать "курсы
> молодого бойца" по собиранию пакетов и взаимодействию с
> апстримом время от времени, если будет технология ведения таких
> "уроков". Не передний край, но для расширения рядов тим,
> по-моему, было бы полезно.

Те, кто был на LVEE, могли зацепить доклад[1] по LiLaLo[2].
Вчера вот продолжили общение с Игорем насчёт запаковать в ALT :)

(это script + timestamping, позволяет сделать запись консольных
событий с сохранением интервала между стадиями)

[1] http://lvee.org.by/index.php/LVEE_2007_06
[2] http://xgu.ru/wiki/LiLaLo

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

Re: [devel] srpms -> gear

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

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

On Fri, Jul 06, 2007 at 10:37:20AM +0400, Dmitry V. Levin wrote:

>> По факту от этой дельты проку ноль. Кроме того пользователь оказывается
>> лишен возможности делать diff между сборками, чтобы посмотреть что в коде
>> поменялось. Собственно все возможности по работе с кодом идут лесом.
>> От такого подхода масса вреда и никакой пользы. Если хочешь я лично для
>> тебя напишу скриптик, который будет этот тарбол распаковывать.
DVL> Денис, этот скриптик называется gear-update(1).

Спасибо. Чувствую скоро нужно будет писать для самого себя памятку по
использованию gear-*.

Кстати о, не посмотришь на seiros-build-utils, часть из него возможно была
бы интересна в gear, только под более человеческими именами. Утилитки
Status/Pull/Co мне очень жизнь облегчают.

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

http://freesource.info
----------------------------------------------------------------------------
> Что такое "повесить PR"?
Лишить жизни рекламщика?
		-- lav in sisyphus@

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

Re: [devel] srpms -> gear

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

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

On Fri, Jul 06, 2007 at 08:09:48PM +0300, Michael Shigorin wrote:

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

Конкретно в данном случае, пока srpms продолжают выкладываться ты всегда
имеешь возможность откатиться до варианта "как было до git" одной командой
rm -rf.

Опять же, с велосипеда на истребители сразу не пересаживаются, увы.

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

Вот сегодня я проделал опять обновление libspandsp4/asterisk. Раньше эта
процедура, вместе с притиркой патчей, занимала у меня до двух дней. Сейчас
пара скриптиков поверх git позволила мне проделать эту работу менее чем за
час.

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

А кое-где меня уже не раз спасал git-bisect. Возможность пользоваться
которым ты получишь сразу после gear-srpmimport, а аналогов которому у
тебя попросту сейчас нетути.

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

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

А я лентяй, так что пущай за меня поработают скриптики, а я тем временем
буду письма в мейллисте писать.

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

http://freesource.info
----------------------------------------------------------------------------
ЗАКОН УПРАВЛЕНИЯ ВЕЛЛИНГТОНА
 Наверху собираются сливки. И пена тоже.


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

Re: [devel] gitweb

[Dmitry V. Levin]

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

On Tue, Jul 03, 2007 at 01:28:36PM +0400, Dmitry V. Levin wrote:
> On Tue, Jul 03, 2007 at 12:23:29PM +0300, Michael Shigorin wrote:
[...]
> > Сейчас как минимум то, что твой репозиторий для получения списка
> > пакетов обрабатывается в среднем ближе к минуте -- тоже не
> > помогает знакомиться с наработками.
> 
> Зачем человеку может срочно понадобится список всех моих пакетов?
> Я сам на него стараюсь не смотреть. :)
> 
> P.S. Почему gitweb на этой операции так сильно тормозит?

Отвечаю: сильно тормозит gitweb'овская функция git_get_last_activity(),
ибо она вызывает ресурсоёмкую операцию
git for-each-ref '--format=%(committer)' --sort=-committerdate --count=1 refs/heads
для всех git-репозиториев в каталоге.

Всё это делается ради удовольствия лицезреть столбец Last Change, а также
сортировать вывод по этому столбцу.


-- 
ldv

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

Re: [devel] gitweb

[Michael Shigorin]

On Fri, Jul 13, 2007 at 02:52:42AM +0400, Dmitry V. Levin wrote:
> > P.S. Почему gitweb на этой операции так сильно тормозит?
> Отвечаю: сильно тормозит gitweb'овская функция
> git_get_last_activity()

Вот её вывод и стоит кэшировать хотя бы на минуту, а то 
и на час.

Апстриму бы хорошо намекнуть, что per-repo last-changed флажок
из файла или каталога в .git/ может сильно помочь как быстро 
фиксируемый и читаемый таймстамп последнего коммита.

Это давно известный изобретательский принцип "сделай заранее"
-- пока у git-commit или иных утилит есть "на руках" время
изменения, можно очень дёшево его зафиксировать, раз потом 
приходится для того же gitweb долго лопатить историю для
получения этой циферки.

> Всё это делается ради удовольствия лицезреть столбец Last
> Change, а также сортировать вывод по этому столбцу.

Что и так было предсказуемо.

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

Re: [devel] git-bisect

[Michael Shigorin]

On Mon, Jul 09, 2007 at 12:45:00AM +0400, Денис Смирнов wrote:
> А кое-где меня уже не раз спасал git-bisect. Возможность
> пользоваться которым ты получишь сразу после gear-srpmimport,
> а аналогов которому у тебя попросту сейчас нетути.

"Нужны ли мы нам?" (c)

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

PS: http://kerneltrap.org/node/11753

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

Re: [devel] git-bisect

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

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

On Fri, Jul 13, 2007 at 10:14:17PM +0300, Michael Shigorin wrote:

>> А кое-где меня уже не раз спасал git-bisect. Возможность
>> пользоваться которым ты получишь сразу после gear-srpmimport,
>> а аналогов которому у тебя попросту сейчас нетути.
MS> "Нужны ли мы нам?" (c)
MS> В смысле я не разработчик с сотнями или тысячами коммитов 
MS> на руках.  Хотя прекрасно понимаю выгоду для тебя с asterisk.

Ты будешь смеяться, но помогал он мне куда чаще для либы securephp. А ещё
очень помогал чтобы понять "какой [censored] написал этот бред", чтобы
связаться напрямую с автором бреда, и объяснить ему как перестать быть
[censored] а стать белым и пушистым :)

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

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

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

http://freesource.info
----------------------------------------------------------------------------
Программисты не умирают... они теряют память...

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

Re: [devel] gitweb

[Dmitry V. Levin]

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

On Fri, Jul 13, 2007 at 09:40:12AM +0300, Michael Shigorin wrote:
> On Fri, Jul 13, 2007 at 02:52:42AM +0400, Dmitry V. Levin wrote:
> > > P.S. Почему gitweb на этой операции так сильно тормозит?
> > Отвечаю: сильно тормозит gitweb'овская функция
> > git_get_last_activity()
> 
> Вот её вывод и стоит кэшировать хотя бы на минуту, а то 
> и на час.
> 
> Апстриму бы хорошо намекнуть, что per-repo last-changed флажок
> из файла или каталога в .git/ может сильно помочь как быстро 
> фиксируемый и читаемый таймстамп последнего коммита.
> 
> Это давно известный изобретательский принцип "сделай заранее"
> -- пока у git-commit или иных утилит есть "на руках" время
> изменения, можно очень дёшево его зафиксировать, раз потом 
> приходится для того же gitweb долго лопатить историю для
> получения этой циферки.

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

http://git.altlinux.org/people/ldv/packages/?p=girar.git;a=commit;h=37e10c5ff36211f8abc860ace72c58cbc3d32f76

Так что скоро наш gitweb будет работать быстрее.


-- 
ldv

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