Re: [devel] [SCM] packages/qemu: heads/master

Re: [devel] [SCM] packages/qemu: heads/master

[Dmitry V. Levin]

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

Aleksey, PLEASE STOP poisoning repositories!

On Wed, Dec 30, 2009 at 04:28:27PM +0300, Aleksey Avdeev wrote:
> Update of /people/solo/packages/qemu.git
> 
> Changes statistics since `0.11.92-alt1' follows:
>  qemu.spec |    8 +++++---
>  1 files changed, 5 insertions(+), 3 deletions(-)
> 
> Changelog since `0.11.92-alt1' follows:
> commit 44d98bdd8a0f17cb8edce47186bc5962eb6e2ce8
> Author: Aleksey Avdeev <solo@altlinux>
> Date:   Sun Dec 27 05:01:07 2009 +0300
> 
>     Remove BuildRequires libvde2.2
>     
>     Signed-off-by: Aleksey Avdeev <solo@altlinux>
> 
> commit 47d742b0fdd88badb8197d3526845d98d85330df
> Author: Aleksey Avdeev <solo@altlinux>
> Date:   Sun Dec 27 04:24:45 2009 +0300
> 
>     qemu.spec: Update BuildRequires for backports
>     
>     Signed-off-by: Aleksey Avdeev <solo@altlinux>
> 
> commit f0a1182749c24c31bb6e7c555c05ca6a849cbb5b
> Merge: b4056f1fe48ed8cee3073276cda1e6d9171db09b b936e08ac4383f23fc068a96cebf94bcb3921df5
> Author: Aleksey Avdeev <solo@altlinux>
> Date:   Sun Dec 27 03:44:15 2009 +0300
> 
>     Merge branch 'ALT/qemu/sample/spec'
>     
>     Conflicts:
>     	qemu.spec
>     
>     Signed-off-by: Aleksey Avdeev <solo@altlinux>
> 
> commit b936e08ac4383f23fc068a96cebf94bcb3921df5
> Merge: 62d4d5454750a346f9de4ecc87a24b842e03cc0c 69e4cf60f5273c717049a97276a6aa6086e54bdb
> Author: Aleksey Avdeev <solo@altlinux>
> Date:   Sun Dec 27 03:41:30 2009 +0300
> 
>     Merge branch 'ALT/release/distr/program' of git://git.altlinux.org/people/solo/public/specs into ALT/qemu/sample/spec
> 
> commit 62d4d5454750a346f9de4ecc87a24b842e03cc0c
> Author: Aleksey Avdeev <solo@altlinux>
> Date:   Sun Dec 27 03:41:01 2009 +0300
> 
>     renamed: sample.spec -> qemu.spec
>     
>     Signed-off-by: Aleksey Avdeev <solo@altlinux>
> 
> commit 69e4cf60f5273c717049a97276a6aa6086e54bdb
> Merge: a11473408bafcc296820c49cb308979a1cb4f1c4 e474b767d720c2ef4f93a9b82237a1442cacd6bb
> Author: Aleksey Avdeev <solo@altlinux>
> Date:   Sun Aug 16 19:49:51 2009 +0400
> 
>     Merge branch 'ALT/release/auto/program' into ALT/release/distr/program
> 
> commit e474b767d720c2ef4f93a9b82237a1442cacd6bb
> Merge: e1e972358aa5d62e017865d04ed268ff3eb044da ac8bb6364cd7432255b61a64d147c1691635ea7f
> Author: Aleksey Avdeev <solo@altlinux>
> Date:   Sun Aug 16 19:35:33 2009 +0400
> 
>     Merge branch 'ALT/release/auto/empty' into ALT/release/auto/program
>     
>     Conflicts:
>     
>     	sample.spec
>     
>     Signed-off-by: Aleksey Avdeev <solo@altlinux>
> 
> commit e1e972358aa5d62e017865d04ed268ff3eb044da
> Author: Aleksey Avdeev <solo@altlinux>
> Date:   Sun Aug 16 19:31:55 2009 +0400
> 
>     Update spec
>     
>     Signed-off-by: Aleksey Avdeev <solo@altlinux>
> 
> commit ac8bb6364cd7432255b61a64d147c1691635ea7f
> Author: Aleksey Avdeev <solo@altlinux>
> Date:   Wed Aug 5 19:46:30 2009 +0400
> 
>     Release: %branch_release <realese>
>     
>     Signed-off-by: Aleksey Avdeev <solo@altlinux>
> 
> commit e404004558242f9a9925896d186e5571bb0b9c12
> Author: Aleksey Avdeev <solo@altlinux>
> Date:   Wed Aug 5 18:43:54 2009 +0400
> 
>     Spec clean
>     
>     Signed-off-by: Aleksey Avdeev <solo@altlinux>
> 
> commit a11473408bafcc296820c49cb308979a1cb4f1c4
> Author: Aleksey Avdeev <solo@altlinux>
> Date:   Sat Aug 8 05:02:04 2009 +0400
> 
>     cleanup_spec sample.spec
>     
>     Signed-off-by: Aleksey Avdeev <solo@altlinux>
> 
> commit 9ffb100cc21471ad036cace518d509fbb2a41a41
> Merge: ff58fef6d28be84c58d03e2407307c5c7fa3973f 9a8575f60fa4bf074200158fa57be7e34a1a1d56
> Author: Aleksey Avdeev <solo@altlinux>
> Date:   Wed Aug 5 20:20:34 2009 +0400
> 
>     Merge branch 'ALT/release/distr/empty' into ALT/release/distr/program
>     
>     Conflicts:
>     
>     	sample.spec
>     
>     Signed-off-by: Aleksey Avdeev <solo@altlinux>
> 
> commit 9a8575f60fa4bf074200158fa57be7e34a1a1d56
> Author: Aleksey Avdeev <solo@altlinux>
> Date:   Wed Aug 5 19:46:30 2009 +0400
> 
>     Release: %branch_release <realese>
>     
>     Signed-off-by: Aleksey Avdeev <solo@altlinux>
> 
> commit 9a37b039023693d6acabf95989759128b9b15ec9
> Author: Aleksey Avdeev <solo@altlinux>
> Date:   Wed Aug 5 18:43:54 2009 +0400
> 
>     Spec clean
>     
>     Signed-off-by: Aleksey Avdeev <solo@altlinux>
> 
> commit ff58fef6d28be84c58d03e2407307c5c7fa3973f
> Merge: c4140b9148585120a75131e8eefc256695ca9ec6 76e354b12f8d2e1dadc440ecdbd28522dabf5000
> Author: Aleksey Avdeev <solo@altlinux>
> Date:   Fri Feb 6 17:20:28 2009 +0300
> 
>     Merge branch 'ALT/reliase/distr/empty' into ALT/reliase/distr/program
> 
> commit 76e354b12f8d2e1dadc440ecdbd28522dabf5000
> Author: Aleksey Avdeev <solo@altlinux>
> Date:   Fri Feb 6 17:15:54 2009 +0300
> 
>     Add M50 distr
>     
>     Signed-off-by: Aleksey Avdeev <solo@altlinux>
> 
> commit c4140b9148585120a75131e8eefc256695ca9ec6
> Merge: 2c7fc545b1d40473284ac6116e636e88ff6e7d38 15bdf2bf1b44369190136a20a65d25eb897f3cf3
> Author: Aleksey Avdeev <solo@altlinux>
> Date:   Fri Nov 7 23:38:17 2008 +0300
> 
>     Merge branch 'ALT/reliase/distr/empty' into ALT/reliase/distr/program
> 
> commit 2c7fc545b1d40473284ac6116e636e88ff6e7d38
> Merge: 8283e7672be29f64265f9a9b5313cc064523fd85 fb6f7082521d083165fe85398d2e314bd5210bbd
> Author: Aleksey Avdeev <solo@altlinux>
> Date:   Fri Nov 7 23:35:37 2008 +0300
> 
>     Merge branch 'ALT/reliase/auto/empty' into ALT/reliase/auto/program
>     
>     Conflicts:
>     
>     	sample.spec
>     
>     Signed-off-by: Aleksey Avdeev <solo@altlinux>
> 
> commit 15bdf2bf1b44369190136a20a65d25eb897f3cf3
> Author: Aleksey Avdeev <solo@altlinux>
> Date:   Fri Nov 7 22:58:19 2008 +0300
> 
>     Add switch for distr selected
>     
>     Signed-off-by: Aleksey Avdeev <solo@altlinux>
> 
> commit 8283e7672be29f64265f9a9b5313cc064523fd85
> Author: Aleksey Avdeev <solo@altlinux>
> Date:   Thu Oct 30 15:17:00 2008 +0300
> 
>     http://www.altlinux.org/index.php?title=SampleSpecs/program&oldid=5164
>     
>     Signed-off-by: Aleksey Avdeev <solo@altlinux>
> 
> commit fb6f7082521d083165fe85398d2e314bd5210bbd
> Author: Aleksey Avdeev <solo@altlinux>
> Date:   Thu Oct 30 13:18:28 2008 +0300
> 
>     Set Release: %release_pre%release_base_num[.%release_base_num2][%release_suff]
>     
>     Release default: alt1
>     
>     Signed-off-by: Aleksey Avdeev <solo@altlinux>
> 
> commit 7e2040dfaa902e8c957c9b2fbd65c2a5902d3921
> Author: Vladimir V Kamarzin <vvk@altlinux>
> Date:   Mon Sep 8 14:45:00 2008 +0400
> 
>     http://www.altlinux.org/index.php?title=SampleSpecs/empty&oldid=3464
> 
> commit b05939db33fe55d6fe915bbf4356644b37d35591
> Author: Mikhail Gusarov <dottedmag@altlinux>
> Date:   Mon Sep 8 11:43:00 2008 +0400
> 
>     http://www.altlinux.org/index.php?title=SampleSpecs/empty&oldid=3455
> 
> commit ba7403eb71d6ee0bd080e2028025ed15aeb8b2d2
> Merge: c48ab8d476559c54f2f32042028eeae97dd705d3 fb7b292e129007de4989a1d3e2729420bfedb010
> Author: Denis Klimov <zver@altlinux>
> Date:   Thu Oct 30 01:47:57 2008 +0300
> 
>     http://www.altlinux.org/index.php?title=SampleSpecs/empty&oldid=3443
> 
> commit fb7b292e129007de4989a1d3e2729420bfedb010
> Author: Php Coder <php-coder@altlinux>
> Date:   Wed Jul 16 16:04:00 2008 +0400
> 
>     http://www.altlinux.org/index.php?title=SampleSpecs/empty&oldid=500
> 
> commit 8e5fc9015a4497be9f56f57f587f8877b02de71e
> Author: Mikhail Gusarov <dottedmag@altlinux>
> Date:   Sat Feb 23 09:48:20 2008 +0300
> 
>     http://freesource.info/wiki/AltLinux/Sisyphus/devel/SampleSpecs/program/show?time=2008-02-23+09:48:20
> 
> commit 4977a0c712418a350686ed2fb2105173731a27e8
> Author: Mikhail Gusarov <dottedmag@altlinux>
> Date:   Sat Feb 23 09:46:54 2008 +0300
> 
>     http://freesource.info/wiki/AltLinux/Sisyphus/devel/SampleSpecs/program/show?time=2008-02-23+09:46:54
> 
> commit f67e86c44ca7c1fb39da483d5d4c43e24e8a0fd6
> Author: Php Coder <php-coder@altlinux>
> Date:   Tue Mar 13 14:26:30 2007 +0300
> 
>     http://freesource.info/wiki/AltLinux/Sisyphus/devel/SampleSpecs/program/show?time=2007-03-14:26:30
> 
> commit c48ab8d476559c54f2f32042028eeae97dd705d3
> Author: Php Coder <php-coder@altlinux>
> Date:   Tue Mar 13 14:25:04 2007 +0300
> 
>     http://freesource.info/wiki/AltLinux/Sisyphus/devel/SampleSpecs/empty/show?time=2007-03-13+14:25:04
> 
> commit c49dff96a1a30dab7efb3a92ccf3d0e624492cc2
> Author: Michael Shigorin <mike@altlinux>
> Date:   Wed Oct 12 10:48:27 2005 +0400
> 
>     http://freesource.info/wiki/AltLinux/Sisyphus/devel/SampleSpecs/empty/show?time=2005-10-12+10:48:27
> 
> commit ffd2e15259234a7840afdfc1a4b7c0b459ae3c37
> Author: Sviatoslav Sviridov <svd@altlinux>
> Date:   Mon Sep 26 11:16:01 2005 +0400
> 
>     http://wiki.sisyphus.ru/devel/SampleSpecs/program/show?time=2005-09-26+11:16:01
> 
> commit 3ce613fa0a5ef95e64d71715220a260d4bbec4da
> Author: Andrey Rahmatullin <wrar@altlinux>
> Date:   Sun Sep 25 22:38:46 2005 +0400
> 
>     http://wiki.sisyphus.ru/devel/SampleSpecs/program/show?time=2005-09-25+22:38:46
> 
> commit 1197609f9d2a3ab8fd18c487db7da18b64ba7093
> Author: Andrey Rahmatullin <wrar@altlinux>
> Date:   Sun Sep 25 13:24:04 2005 +0400
> 
>     http://freesource.info/wiki/AltLinux/Sisyphus/devel/SampleSpecs/empty/show?time=2005-09-25+13:24:04
> 
> commit d7d7d39e871684ced52e61aabb133c3d53985ae6
> Author: Php Coder <php-coder@altlinux>
> Date:   Sun Sep 25 12:55:59 2005 +0400
> 
>     http://wiki.sisyphus.ru/devel/SampleSpecs/program/show?time=2005-09-25+12:55:59
> 
> commit 41ae892412fe3d636a8ca4a0e276132a402b9db0
> Author: Php Coder <php-coder@altlinux>
> Date:   Sun Sep 25 12:53:25 2005 +0400
> 
>     http://freesource.info/wiki/AltLinux/Sisyphus/devel/SampleSpecs/empty/show?time=2005-09-25+12:53:25
> 
> commit f006f388a7c1f8044f5a385e757e70aadb2c69f4
> Author: Php Coder <php-coder@altlinux>
> Date:   Sun Sep 25 12:52:26 2005 +0400
> 
>     http://freesource.info/wiki/AltLinux/Sisyphus/devel/SampleSpecs/empty/show?time=2005-09-25+12:52:26
> 
> commit 0b2c5a0c4b12c1f05a385566dbca1c06707ebb61
> Author: Php Coder <php-coder@altlinux>
> Date:   Sun Sep 25 12:49:55 2005 +0400
> 
>     http://freesource.info/wiki/AltLinux/Sisyphus/devel/SampleSpecs/empty/show?time=2005-09-25+12:49:55
> 
> commit d1a5900fb3787a6105268901e7edb78d7fac77af
> Author: Igor Zubkov <icesik@altlinux>
> Date:   Sun Sep 25 12:23:26 2005 +0400
> 
>     http://freesource.info/wiki/AltLinux/Sisyphus/devel/SampleSpecs/empty/show?time=2005-09-25+12:23:26
> 
> commit 0d53305a81b93ad35f8f91639551adb9d4a42e37
> Author: Andrey Rahmatullin <wrar@altlinux>
> Date:   Sun Sep 25 11:11:33 2005 +0400
> 
>     http://wiki.sisyphus.ru/devel/SampleSpecs/program/show?time=2005-09-25+11:11:33
> 
> commit 971d90343aeb8ddcfbb5f3e9579d5cf9c3977c05
> Author: Andrey Rahmatullin <wrar@altlinux>
> Date:   Sat Sep 24 21:29:36 2005 +0400
> 
>     http://freesource.info/wiki/AltLinux/Sisyphus/devel/SampleSpecs/empty/show?time=2005-09-24+21:29:36
> 
> commit 631a99122c49f257f92f23ea387fb5cf00520f4c
> Author: Andrey Rahmatullin <wrar@altlinux>
> Date:   Sat Sep 24 21:16:46 2005 +0400
> 
>     http://wiki.sisyphus.ru/devel/SampleSpecs/program/show?time=2005-09-24+21:16:46
> 
> commit 35f5e943d8f5a14581eca0961462236b35edc3b5
> Author: Andrey Rahmatullin <wrar@altlinux>
> Date:   Sat Sep 24 16:38:19 2005 +0400
> 
>     http://wiki.sisyphus.ru/devel/SampleSpecs/program/show?time=2005-09-24+16:38:19
> 
> Full diff since `0.11.92-alt1' follows:
> diff --git a/qemu.spec b/qemu.spec
> index 2897a6b..eeb4403 100644
> --- a/qemu.spec
> +++ b/qemu.spec
> @@ -70,7 +70,7 @@
>  
>  Name: qemu
>  Version: 0.11.92
> -Release: alt1
> +Release: %branch_release alt1
>  
>  Summary: QEMU CPU Emulator
>  License: GPL/LGPL/BSD
> @@ -87,8 +87,10 @@ Packager: Kirill A. Shutemov <kas@altlinux>
>  %set_verify_elf_method fhs=relaxed
>  %add_strip_skiplist %_datadir/qemu/*
>  
> -BuildRequires: glibc-devel-static libSDL-devel libesd-devel libgnutls-devel libncurses-devel
> -BuildRequires: libpulseaudio-devel libvde-devel libvde2.2 tetex-core zlib-devel libX11-devel
> +BuildRequires(pre): rpm-macros-branch
> +BuildPreReq: libesd-devel
> +BuildRequires: glibc-devel-static libSDL-devel libgnutls-devel libncurses-devel
> +BuildRequires: libpulseaudio-devel libvde-devel tetex-core zlib-devel libX11-devel
>  BuildRequires: libcurl-devel libsasl2-devel libbluez4-devel libcheck-devel libaio-devel
>  BuildRequires: libuuid-devel
>  

-- 
ldv

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

Re: [devel] [SCM] packages/qemu: heads/master

[Aleksey Avdeev]

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

31.12.2009 00:06, Dmitry V. Levin пишет:
> Aleksey, PLEASE STOP poisoning repositories!

?

> 
> On Wed, Dec 30, 2009 at 04:28:27PM +0300, Aleksey Avdeev wrote:
>> Update of /people/solo/packages/qemu.git
>>
>> Changes statistics since `0.11.92-alt1' follows:
>>  qemu.spec |    8 +++++---
>>  1 files changed, 5 insertions(+), 3 deletions(-)
>>
>> Changelog since `0.11.92-alt1' follows:
>> commit 44d98bdd8a0f17cb8edce47186bc5962eb6e2ce8
>> Author: Aleksey Avdeev <solo@altlinux>
>> Date:   Sun Dec 27 05:01:07 2009 +0300
>>
>>     Remove BuildRequires libvde2.2
>>     
>>     Signed-off-by: Aleksey Avdeev <solo@altlinux>
>>
>> commit 47d742b0fdd88badb8197d3526845d98d85330df
>> Author: Aleksey Avdeev <solo@altlinux>
>> Date:   Sun Dec 27 04:24:45 2009 +0300
>>
>>     qemu.spec: Update BuildRequires for backports
>>     
>>     Signed-off-by: Aleksey Avdeev <solo@altlinux>
>>
...
>>  
>>  Name: qemu
>>  Version: 0.11.92
>> -Release: alt1
>> +Release: %branch_release alt1
>>  
>>  Summary: QEMU CPU Emulator
>>  License: GPL/LGPL/BSD
>> @@ -87,8 +87,10 @@ Packager: Kirill A. Shutemov <kas@altlinux>
>>  %set_verify_elf_method fhs=relaxed
>>  %add_strip_skiplist %_datadir/qemu/*
>>  
>> -BuildRequires: glibc-devel-static libSDL-devel libesd-devel libgnutls-devel libncurses-devel
>> -BuildRequires: libpulseaudio-devel libvde-devel libvde2.2 tetex-core zlib-devel libX11-devel
>> +BuildRequires(pre): rpm-macros-branch
>> +BuildPreReq: libesd-devel
>> +BuildRequires: glibc-devel-static libSDL-devel libgnutls-devel libncurses-devel
>> +BuildRequires: libpulseaudio-devel libvde-devel tetex-core zlib-devel libX11-devel
>>  BuildRequires: libcurl-devel libsasl2-devel libbluez4-devel libcheck-devel libaio-devel
>>  BuildRequires: libuuid-devel

PS: Это бэкпорт (ещё не завершённый) сизифовского qemu-0.11.92-alt1: оно
уже собирается и работает (в том числе -- system_powerdown). Регресса
относительно qemu-0.9.0.cvs20070420-alt8 помоему нет (Относительно
сизифовского 0.11.92-alt1 есть: многое пришлось отключить ради
собираемости).

-- 

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



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

Re: [devel] [SCM] packages/qemu: heads/master

[Dmitry V. Levin]

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

On Thu, Dec 31, 2009 at 12:15:21AM +0300, Aleksey Avdeev wrote:
> 31.12.2009 00:06, Dmitry V. Levin пишет:
> > Aleksey, PLEASE STOP poisoning repositories!
> 
> ?

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


-- 
ldv

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

Re: [devel] [SCM] packages/qemu: heads/master

[Aleksey Avdeev]

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

31.12.2009 01:05, Dmitry V. Levin пишет:
> On Thu, Dec 31, 2009 at 12:15:21AM +0300, Aleksey Avdeev wrote:
>> 31.12.2009 00:06, Dmitry V. Levin пишет:
>>> Aleksey, PLEASE STOP poisoning repositories!
>>
>> ?
> 
> Пожалуйста, хватит отравлять нормальные репозитории, вмерживая туда
> засоряющие их коммиты!  Несколько десятков коммитов для того, чтобы
> внести тривиальное изменение в спек!!  Неужели не очевидно, что это
> ужасно???

  Не очевидно, т. к. данный минус перекрывается плюсами:

1. _Сразу_ видно откуда растут данные изменения: сохраняется история
каждой вмерженной фичи.

2. Устаревшая реализация фичи легко меняется на свежую, с помощью мержа.
И как показала практика обновления автоматизатированной генерации
релизов (переход от кучи макросов к %branch_release) -- достаточно
простого мержа.

>  Не говоря уже про тиражирование ошибок в английских словах.

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

PS: Я не настаиваю именно на своём варианте: Мантейнер пакета вполне
может недавать мне ACL и/или сам сделать требуемые изменения (например
через git cherry-pick, и/или другим способом).

-- 

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



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

Re: [devel] [SCM] packages/qemu: heads/master

[Anton Farygin]

31.12.2009 01:39, Aleksey Avdeev пишет:
> 31.12.2009 01:05, Dmitry V. Levin пишет:
>> On Thu, Dec 31, 2009 at 12:15:21AM +0300, Aleksey Avdeev wrote:
>>> 31.12.2009 00:06, Dmitry V. Levin пишет:
>>>> Aleksey, PLEASE STOP poisoning repositories!
>>>
>>> ?
>>
>> Пожалуйста, хватит отравлять нормальные репозитории, вмерживая туда
>> засоряющие их коммиты!  Несколько десятков коммитов для того, чтобы
>> внести тривиальное изменение в спек!!  Неужели не очевидно, что это
>> ужасно???
>
>    Не очевидно, т. к. данный минус перекрывается плюсами:
>
> 1. _Сразу_ видно откуда растут данные изменения: сохраняется история
> каждой вмерженной фичи.
>
> 2. Устаревшая реализация фичи легко меняется на свежую, с помощью мержа.
> И как показала практика обновления автоматизатированной генерации
> релизов (переход от кучи макросов к %branch_release) -- достаточно
> простого мержа.

Алексей, я бы не хотел мержить такие изменения к себе.

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

Перечисленные плюсы мне не очевидны.

Re: [devel] [SCM] packages/qemu: heads/master

[Aleksey Avdeev]

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

31.12.2009 12:58, Anton Farygin пишет:
> 31.12.2009 01:39, Aleksey Avdeev пишет:
>> 31.12.2009 01:05, Dmitry V. Levin пишет:
>>> On Thu, Dec 31, 2009 at 12:15:21AM +0300, Aleksey Avdeev wrote:
>>>> 31.12.2009 00:06, Dmitry V. Levin пишет:
>>>>> Aleksey, PLEASE STOP poisoning repositories!
>>>>
>>>> ?
>>>
>>> Пожалуйста, хватит отравлять нормальные репозитории, вмерживая туда
>>> засоряющие их коммиты!  Несколько десятков коммитов для того, чтобы
>>> внести тривиальное изменение в спек!!  Неужели не очевидно, что это
>>> ужасно???
>>
>>    Не очевидно, т. к. данный минус перекрывается плюсами:
>>
>> 1. _Сразу_ видно откуда растут данные изменения: сохраняется история
>> каждой вмерженной фичи.
>>
>> 2. Устаревшая реализация фичи легко меняется на свежую, с помощью мержа.
>> И как показала практика обновления автоматизатированной генерации
>> релизов (переход от кучи макросов к %branch_release) -- достаточно
>> простого мержа.
> 
> Алексей, я бы не хотел мержить такие изменения к себе.
> 
> Нельзя ли просто внести один коммит, изменяющий то, что нужно, вместо
> десятка странных ?

  Там есть "странные" коммиты как миниум 2х типов:

1. Всё что растёт из solo/public/specs.git -- можно оторвать мерж,
оставив привнесённые им изменения.

2. Поэтапный отрыв фич (сделано по коммиту на фичу). Это я бы пока
оставил: после бэкпорта на 4.0, логично иметь бэкпорт и на 4.1... Думаю,
там можно будет вернуть часть оторванного.

> 
> Перечисленные плюсы мне не очевидны.

  Для меня -- очевидны и весьма существенны. Но не настаиваю:
мантейнер-то не я.

-- 

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



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

[devel] I: Бэкпорты qemu-0.11.92 (vas: Re: [SCM] packages/qemu: heads/master)

[Aleksey Avdeev]

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

Приветствую.

  Я подготовил бэкпорты qemu-0.11.92 на:

5.1 -- 0.11.92-alt0.M51.1 (см.
<http://git.altlinux.org/people/solo/packages/?p=qemu.git;a=commit;h=7248397f8e47ded7d6f60d52b9ccd2844d14b9c3>):
ничего существенного, окромя смены релиза. Возможно имеет смысл просто
скопировать сизифовский qemu-0.11.92-alt1 в данный репозиторий.

5.0 -- 0.11.92-alt0.M50.1 (см.
<http://git.altlinux.org/people/solo/packages/?p=qemu.git;a=commit;h=5f7535ca1876d363d5dd9122986265b9a4fdbfb3>):
отключена поддержка KVM

4.1 -- 0.11.92-alt0.M41.1 (см.
<http://git.altlinux.org/people/solo/packages/?p=qemu.git;a=commit;h=d99f4382e4a817221be534e210f50ed860c6a876>):
отключены пр. п. + bluez, vde и AIO.

4.0 -- 0.11.92-alt0.M40.1 (см.
<http://git.altlinux.org/people/solo/packages/?p=qemu.git;a=commit;h=0ca6accd8c0cc55fee8e63dceadb1e2aa5a5ea3d>):
отключены пр. п. + PulseAudio.

  По репозиторию:

1. Коммиты соответствуют атомарным изменениям спека. Это позволило
минимизировать деградацию функционала для каждого из репозиториев (за
счёт разноса по веткам и переупорядовачивания).

2. В master (см.
<http://git.altlinux.org/people/solo/packages/?p=qemu.git;a=shortlog;h=refs/heads/master>):

а) перенос пакетов требующихся для отключаемых фич из общих
BuildRequires в индивидуальные BuildPreReq (так проще контролировать их
удаление);

б) удаление зависимости на libvde2.2 (зависимость нужна для 5.1 и 5.0,
для Сизифа лишняя, в 4.* -- ломает сборку);

в) первичный мерж с specs.git (мне проще, когда он есть).

2kas: Прошу NMU/ACL. Если для этого требуется переписать историю (см.
цитирование ниже) -- прошу указать что именно выкинуть, а что --
объединить...

03.01.2010 19:00, Aleksey Avdeev пишет:
> 31.12.2009 12:58, Anton Farygin пишет:
...
>>
>> Алексей, я бы не хотел мержить такие изменения к себе.
>>
>> Нельзя ли просто внести один коммит, изменяющий то, что нужно, вместо
>> десятка странных ?
> 
>   Там есть "странные" коммиты как миниум 2х типов:
> 
> 1. Всё что растёт из solo/public/specs.git -- можно оторвать мерж,
> оставив привнесённые им изменения.
> 
> 2. Поэтапный отрыв фич (сделано по коммиту на фичу). Это я бы пока
> оставил: после бэкпорта на 4.0, логично иметь бэкпорт и на 4.1... Думаю,
> там можно будет вернуть часть оторванного.
> 
>>
>> Перечисленные плюсы мне не очевидны.
> 
>   Для меня -- очевидны и весьма существенны. Но не настаиваю:
> мантейнер-то не я.

-- 

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



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

Re: [devel] [SCM] packages/qemu: heads/master

[Dmitry V. Levin]

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

On Thu, Dec 31, 2009 at 01:39:34AM +0300, Aleksey Avdeev wrote:
> 31.12.2009 01:05, Dmitry V. Levin пишет:
> > On Thu, Dec 31, 2009 at 12:15:21AM +0300, Aleksey Avdeev wrote:
> >> 31.12.2009 00:06, Dmitry V. Levin пишет:
> >>> Aleksey, PLEASE STOP poisoning repositories!
> >>
> >> ?
> > 
> > Пожалуйста, хватит отравлять нормальные репозитории, вмерживая туда
> > засоряющие их коммиты!  Несколько десятков коммитов для того, чтобы
> > внести тривиальное изменение в спек!!  Неужели не очевидно, что это
> > ужасно???
> 
>   Не очевидно, т. к. данный минус перекрывается плюсами:
> 
> 1. _Сразу_ видно откуда растут данные изменения: сохраняется история
> каждой вмерженной фичи.

В данном случае у изменения в несколько строк история в 42 коммита:

$ git diff --stat 0.11.92-alt1..0.11.92-alt1-42-g44d98bd
 qemu.spec |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)

И чтение вывода git log 0.11.92-alt1..0.11.92-alt1-42-g44d98bd не наводит
(меня, по крайней мере) не на какие конструктивные мысли.

> 2. Устаревшая реализация фичи легко меняется на свежую, с помощью мержа.
> И как показала практика обновления автоматизатированной генерации
> релизов (переход от кучи макросов к %branch_release) -- достаточно
> простого мержа.

Легко меняется?  Там всего несколько строк изменений, однако _каждый_ merge
приводит к конфликту, который приходится исправлять вручную.

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

Историю коммитов невозможно пропатчить.

> PS: Я не настаиваю именно на своём варианте:

Однако вы настаиваете на своём методе, который по сути есть ни что иное
как графо^Wгитоманство и перевод чернил^Wкоммитов.  Грустно смотреть, на
что порой расходуют себя умные люди.


-- 
ldv

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

[devel] о культуре работы с git-репозиториями (was: [SCM] packages/qemu: heads/master)

[Michael Shigorin]

On Sun, Jan 10, 2010 at 04:08:13AM +0300, Dmitry V. Levin wrote:
> Историю коммитов невозможно пропатчить.

Возможно, но работать с таким репозиторием другим крайне неудобно.

> > PS: Я не настаиваю именно на своём варианте:
> Однако вы настаиваете на своём методе, который по сути есть ни
> что иное как графо^Wгитоманство и перевод чернил^Wкоммитов.
> Грустно смотреть, на что порой расходуют себя умные люди.

Дим, если ты (наивно) полагал, что на gear-srpmimport поиск
вариантов и преподавание хороших примеров закончится -- это
не так.

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

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

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

-- 
http://www.altlinux.org/Kernelnotes/mike

Re: [devel] о культуре работы с git-репозиториями

[Motsyo Gennadi aka Drool]

10.01.2010 13:32, Michael Shigorin пишет:
> Меня вот тошнит от мегапатча или вообще бухнутого в тарбол
> master, в котором леший ногу сломит...
> ...а между тем srpm с разложенными патчами куда
> дружественней и уважительней по отношению к другим, чем такое.

	Большой +1

Re: [devel] о культуре работы с git-репозиториями (was: [SCM] packages/qemu: heads/master)

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

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

On Sun, Jan 10, 2010 at 01:32:54PM +0200, Michael Shigorin wrote:

MS> Меня вот тошнит от мегапатча или вообще бухнутого в тарбол
MS> master, в котором леший ногу сломит -- у тебя таких гитов
MS> довольно много, а между тем srpm с разложенными патчами куда
MS> дружественней и уважительней по отношению к другим, чем такое.

Миш, тут такая тема -- как мы относимся к srpm. Сейчас к srpm
"официальное" отношение, что это просто промежуточный формат для сборки.

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

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

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

У нас нет централизованного хранилица git repo, как это ни парадоксально
звучит. Скажем nginx сейчас собирают несколько человек, вопрос -- какой
repo можно считать "основным" ?

По идее -- это git.alt/gears/n/nginx. Но вот в чем проблема -- этот репо
содержит исключительно тот бранч, что в моем репо именуется 'master'. А,
например, того бранча, который у меня называется 'upstream' там нет.

И восстановить структуру бранчей пользуясь только репо в
git.alt/gears/n/nginx невозможно с разумными затратами времени.

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

Только вот неудобно так работать, очень :(

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

Надо :(

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

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

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

Re: [devel] о культуре работы с git-репозиториями

[Michael Shigorin]

On Sun, Jan 10, 2010 at 04:11:59PM +0300, Денис Смирнов wrote:
> MS> Меня вот тошнит от мегапатча или вообще бухнутого в тарбол
> MS> master, в котором леший ногу сломит -- у тебя таких гитов
> MS> довольно много, а между тем srpm с разложенными патчами куда
> MS> дружественней и уважительней по отношению к другим, чем такое.
> Миш, тут такая тема -- как мы относимся к srpm. Сейчас к srpm
> "официальное" отношение, что это просто промежуточный формат для сборки.
> С этой точки зрения не важно в каком виде результат плюхается в srpm, но
> важно насколько удобно работать с чужим git-репозиторием.
[...]
> А вот если сборка делается через генерирование патчей, тогда у
> нас есть вся необходимая информация.  Только вот неудобно так
> работать, очень :(

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

"К другим" -- это не только @altlinux.

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

Re: [devel] о культуре работы с git-репозиториями

[Igor Zubkov]

10 января 2010 г. 15:31 пользователь Michael Shigorin написал:
> On Sun, Jan 10, 2010 at 04:11:59PM +0300, Денис Смирнов wrote:
>> А вот если сборка делается через генерирование патчей, тогда у
>> нас есть вся необходимая информация.  Только вот неудобно так
>> работать, очень :(
>
> Зато можно ругать старые дебиановские мегапатчи и тихонько
> отмалчиваться в тряпочку, когда наконец функциональный аналог
> добрался до нас -- при том, что и там небось давно уж можно
> было полазить по alioth и найти scm repo данного конкретного
> человека по нужному пакету.

Так, значит ты ещё не знаешь что они отказались от своих больших мега-патчей? :)

http://www.opennet.ru/opennews/art.shtml?num=24364

И мы сейчас идёт туда от куда Debian уже уходит. И правильно делает.

-- 
Igor Zubkov
http://hi.im/ice

Re: [devel] о культуре работы с git-репозиториями

[Dmitry V. Levin]

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

On Tue, Jan 12, 2010 at 03:07:01AM +0200, Igor Zubkov wrote:
[...]
> Так, значит ты ещё не знаешь что они отказались от своих больших мега-патчей? :)
> 
> http://www.opennet.ru/opennews/art.shtml?num=24364
> 
> И мы сейчас идёт туда от куда Debian уже уходит. И правильно делает.

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


-- 
ldv

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

[devel] стили работы с git-репозиториями

[Michael Shigorin]

On Tue, Jan 12, 2010 at 04:24:33AM +0300, Dmitry V. Levin wrote:
> > Так, значит ты ещё не знаешь что они отказались от своих
> > больших мега-патчей? :)

Знаю, конечно.  Уже успел забыть, как новая система работы
с patch series обзывается. :)

> > И мы сейчас идёт туда от куда Debian уже уходит.
> > И правильно делает.
> Вышеупомянутое "нововведение" у нас реализовано изначально.
> Однако у нас не стоит задача перейти на какой-то один
> единственно правильный стиль упаковки.  В частности, чем ближе
> мейнтейнер к апстриму, тем ему более естественно оперировать
> коммитами, а не патчами.  Так что пользуйтесь инструментом
> разумно и не впадайте в крайности.

Думаю выделить и задокументировать три стиля:

- "админский", а-ля gear-srpmimport:
  + как инициализироваться;
  + как добавлять/убирать/обновлять патчи
- "неапстримный разработчик", с бранчами:
  + хорошо бы с внятным выделением отдельных патчей в gear rules
- "апстримный разработчик", хоть с одним master:
  + для него наличие непустого патча -- либо alt-specific,
    либо ситуация временная и потому особенно их охорашивать
    может не быть смысла.

Буду благодарен за ссылки на уже существующие и рекомендуемые
страницы на вики или письма в архиве (есть и свой, например,
с описанием каскадного мержа бранчей в mutt1.5).  Ну и за критику
предложенной категоризации или признаков стилей.

PS: а потом бы придумать микродокументацию под .gear, чтоб можно
было сразу понять _намерение_ выбора стиля и не ошибиться при,
скажем, смене сопровождающего пакет...

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

Re: [devel] о культуре работы с git-репозиториями (was: [SCM] packages/qemu: heads/master)

[Afanasov Dmitry]

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

On Sun, Jan 10, 2010 at 04:11:59PM +0300, Денис Смирнов wrote:
> On Sun, Jan 10, 2010 at 01:32:54PM +0200, Michael Shigorin wrote:
> 
> MS> Меня вот тошнит от мегапатча или вообще бухнутого в тарбол
> MS> master, в котором леший ногу сломит -- у тебя таких гитов
> MS> довольно много, а между тем srpm с разложенными патчами куда
> MS> дружественней и уважительней по отношению к другим, чем такое.
> 
> Миш, тут такая тема -- как мы относимся к srpm. Сейчас к srpm
> "официальное" отношение, что это просто промежуточный формат для сборки.
что я считаю бредом. пока у gear не будет зависимостей, пока apt-get
source не поставит нужную репу, пока не появится новый gear package
manager, gear будет не более чем хранилищем, а результатом будет всё
тот же srpm.

srpm не промежуточный формат, srpm - результат. хехе, hasher и тот
зависимости вычисляет через rpmquery -qR <srpm>.

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

/me представить страшно, если на packages.<distr>.org перестанут как у нас
выкладывать патчи.

> Првада раскладывать по файликам полезно с другой точки зрения.
кажись именно её я и озвучил :)

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

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

проще говоря: каждая репа - это новый бранч.
-- 
С уважением
Афанасов Дмитрий

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

Re: [devel] о культуре работы с git-репозиториями (was: [SCM] packages/qemu: heads/master)

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

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

On Sun, Jan 10, 2010 at 04:32:48PM +0300, Afanasov Dmitry wrote:

AD> что я считаю бредом. пока у gear не будет зависимостей, пока apt-get
AD> source не поставит нужную репу, пока не появится новый gear package
AD> manager, gear будет не более чем хранилищем, а результатом будет всё
AD> тот же srpm.
AD> srpm не промежуточный формат, srpm - результат. хехе, hasher и тот
AD> зависимости вычисляет через rpmquery -qR <srpm>.

Вот потому он и является промежуточным форматом. Оригинал -- это spec, в
gear repo. Результат -- это rpm. А srpm это так, дополнительный, но
_действительно важный_ результат. Важный в том числе для apt-get source,
например :)

AD> важно - готовый патч проще взять и приложить, чем взять репу и вычислять,
AD> откуда что растет.
AD> /me представить страшно, если на packages.<distr>.org перестанут как у нас
AD> выкладывать патчи.

Я попробую пояснить, только попрошу не обижаться.

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

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

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

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

Работа по формированию отдельных патчей занимат в разы больше времени, чем
сборка с двумя бранчами (upstream/master), которой я сейчас пользуюсь.

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

Если меня попытаться обязать паковать более медленным образом -- я просто
перевешу большинство своих пакетов на nobody, и буду паковать их у себя
локально ровно так, как мне необходимо для работы. В результате не будет
"более красиво упакованных пакетов", их будет тривиально меньше.

Думаю что аналогичный подход у большинства мантейнеров. 

Обвинять в этом git как технологию также неправильно. git дал возможность
работать _более быстро_, но одним патчем. При этом тем, кто хочет
разобраться в этом пакете -- придется смотреть в git repo, а не srpm.



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

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

Я с интересом будут обсуждать схемы организации работы, которые позволят
удобнее работать с git repo, в том числе чужими. Это нужное дело.
Обсуждать то, как облегчить жизнь тем кто хочет продолжать использовать
srpm ценой затрат _моего личного времени_ -- я готов только если эти
любители srpm за свое нежелание учиться и желание тратить мое время начнут
платить мне деньги.

AD> кажись именно её я и озвучил :)

Возможно я не понял :)

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

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

AD> видно это тогда, когда
AD> репозитарии на работе, дома и на git.alt рассинхронизируются - в этом
AD> случае мы получаем merge с раздвоением истории.

Это происходит, скорее всего вот почему:

есть некий HEAD в вашем репо на git.alt
вы сделали коммит A дома, и не запушили его
потом сделали коммит B на работе (поверх HEAD) и запушили его
потом пришли домой, и, опаньки! нужен merge.

решаются такие вещи тривиально:
1. перед началом работы не забывать делать pull
2. после окончания работы делать push
3. если работа длительная, параллельная, то это действительно по сути
отдельный бранч. Но часто достаточно воспользоваться всего лишь git
rebase.

AD> проще говоря: каждая репа - это новый бранч.

Нет.

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

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

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

Re: [devel] о культуре работы с git-репозиториями (was: [SCM] packages/qemu: heads/master)

[Afanasov Dmitry]

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

On Sun, Jan 10, 2010 at 07:01:04PM +0300, Денис Смирнов wrote:
> On Sun, Jan 10, 2010 at 04:32:48PM +0300, Afanasov Dmitry wrote:
> 
> AD> что я считаю бредом. пока у gear не будет зависимостей, пока apt-get
> AD> source не поставит нужную репу, пока не появится новый gear package
> AD> manager, gear будет не более чем хранилищем, а результатом будет всё
> AD> тот же srpm.
> AD> srpm не промежуточный формат, srpm - результат. хехе, hasher и тот
> AD> зависимости вычисляет через rpmquery -qR <srpm>.
> 
> Вот потому он и является промежуточным форматом. Оригинал -- это spec, в
> gear repo. Результат -- это rpm. А srpm это так, дополнительный, но
> _действительно важный_ результат. Важный в том числе для apt-get source,
> например :)
> 
> AD> важно - готовый патч проще взять и приложить, чем взять репу и вычислять,
> AD> откуда что растет.
> AD> /me представить страшно, если на packages.<distr>.org перестанут как у нас
> AD> выкладывать патчи.
> 
> Я попробую пояснить, только попрошу не обижаться.
меня ж не матерят, чего ж обижаться.

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

> Мне, как мантейнеру, не платят ни копейки. И мои _обязательства_ поэтому
> ограничиваются всего лишь одним пунктом -- не мешать жить другим. Если
> подробнее -- соблюдать полиси и не кидать заведомые бомбы в Сизиф.
>
> Так вот, _заставить_ меня выполнять упаковку пакетом невозможно, никак.
> Просто если у меня есть возможность -- я отправлю пакет в Сизиф (чтобы
> коллегам жизнь облегчить, да и чтобы самому потом не потерять).
> 
> На подобные вещи у меня есть некоторый ограниченный ресурс времени, ибо
> это _свободное_ время (а еще и работать надо), и _не все_ свободное время
> (ибо отдыхать от компа надо).
> 
аругменты: 1. не платят, 2. заставить выполнять невозможно, 3. ограничение
по времени.

единственное, solo@ нарушает обязательство не мешать.

одно но:
> Если меня попытаться обязать паковать более медленным образом -- я просто
> перевешу большинство своих пакетов на nobody, и буду паковать их у себя
> локально ровно так, как мне необходимо для работы.


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



> Обвинять в этом git как технологию также неправильно.
а вот здесь стоять. я застал последние месяцы работы incoming и буквально
сразу сел на git.alt, не успев ни привыкнуть ни испытать на себе все
преимущества и недостатки incoming.

я не имею претензий к git - после cvs и svn для меня это лучшая система
контроля версий. я и использую её как систему контроля. но gear - это VCS,
а archive extractor, который мы пытаемся использовать как конейнер для
пакета.

ой, ну а дальше меня опять утягивает на философию :)
-- 
 С уважением
 Афанасов Дмитрий

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

Re: [devel] о культуре работы с git-репозиториями (was: [SCM] packages/qemu: heads/master)

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

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

On Sun, Jan 10, 2010 at 08:19:49PM +0300, Afanasov Dmitry wrote:

AD> вот только те же аргументы может привести и solo@, с обсуждения методов
AD> которого мы и начали.

Разумеется может. И, мало того, имеет полное право в своем git творить это
безобразие. Однако безобразием быть оо от этого не перестает, и кому-то
другому с этим репозиторием будет работать уже грустно.

AD> аругменты: 1. не платят, 2. заставить выполнять невозможно, 3. ограничение
AD> по времени.

Собственно 1 и 2-е связаны.

AD> единственное, solo@ нарушает обязательство не мешать.

Частично. Если этот пакет собирается для себя и по сути является
contrib'ом -- то это совершенно приемлимо.

Если это чужой пакет -- то это совершенно неприемлимо.

В остальных случаях полутона :)

AD> одно но:
>> Если меня попытаться обязать паковать более медленным образом -- я просто
>> перевешу большинство своих пакетов на nobody, и буду паковать их у себя
>> локально ровно так, как мне необходимо для работы.
>> Думаю что аналогичный подход у большинства мантейнеров. 
AD> именно. как и у solo@. значит либо не обсуждаем его ведения репозитария,
AD> либо забираем его пакеты? 

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

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

>> Обвинять в этом git как технологию также неправильно.
AD> а вот здесь стоять. я застал последние месяцы работы incoming и буквально
AD> сразу сел на git.alt, не успев ни привыкнуть ни испытать на себе все
AD> преимущества и недостатки incoming.

:)

AD> я не имею претензий к git - после cvs и svn для меня это лучшая система
AD> контроля версий. я и использую её как систему контроля. но gear - это VCS,
AD> а archive extractor, который мы пытаемся использовать как конейнер для
AD> пакета.

Вообще говоря git это не честная VCS. git это FS с функциями VCS :)
И поверх которой реализуется любая VCS какую хочешь. Но это все уже
начинает требовать [JT} в теме :)

AD> ой, ну а дальше меня опять утягивает на философию :)

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

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

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

[devel] [JT] о культуре работы с git-репозиториями (was: [SCM] packages/qemu: heads/master)

[Afanasov Dmitry]

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

On Sun, Jan 10, 2010 at 10:58:27PM +0300, Денис Смирнов wrote:
> On Sun, Jan 10, 2010 at 08:19:49PM +0300, Afanasov Dmitry wrote:
> 
> AD> единственное, solo@ нарушает обязательство не мешать.
> 
> Частично. Если этот пакет собирается для себя и по сути является
> contrib'ом -- то это совершенно приемлимо.
> 
> Если это чужой пакет -- то это совершенно неприемлимо.
> 
> В остальных случаях полутона :)
в моём случае тон один - чем больше времени требуется на изучение
репозитария, тем меньше шанс, что я им займусь, каким бы nobody хотя и
нужным он ни был. и, понимая это, стараюсь уменьшить время на изучение в
своих репозитариях. часто переделывая их с нуля.

> Обсуждать и _требовать_ -- разные вещи.
здесь требуют. и чем старше аксакал, тем более безапелляционны его
требования :)

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

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

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

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

Re: [devel] [JT] о культуре работы с git-репозиториями (was: [SCM] packages/qemu: heads/master)

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

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

On Mon, Jan 11, 2010 at 12:44:41AM +0300, Afanasov Dmitry wrote:

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

И это хорошо и правильно.

AD> здесь требуют. и чем старше аксакал, тем более безапелляционны его
AD> требования :)

Иногда полезно игнорировать форму сообщения, воспринимая только смысл :)

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

:)

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

Можно трезво оценить разумность. Скажем 3 года назад, я тратил на работу с
пакетами около 10 часов в неделю. Так как планировать такие вещи для себя
я считаю разумным на год вперед, то для того чтобы экономить 1% времени
сборки я мог себе позволить потратить до 5-и часов времени на изучение.

Вот такая вот арифметика. Жаль не всегда получается все так посчитать :)

Сейчас эти цифры в 10 раз ниже, увы.

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

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

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

Re: [devel] о культуре работы с git-репозиториями

[Michael Shigorin]

On Sun, Jan 10, 2010 at 07:01:04PM +0300, Денис Смирнов wrote:
> Работа по формированию отдельных патчей занимат в разы больше
> времени, чем сборка с двумя бранчами (upstream/master), которой
> я сейчас пользуюсь.  С радостью отдам большинство своих пакетов
> тем, кто захочет их упаковать лучше.

Откуда они возьмутся, если желающие посмотрят на sisyphus.ru,
git.altlinux.org, ужаснутся и пойдут дальше?

> Думаю что аналогичный подход у большинства мантейнеров. 

И он ужасен. :(

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

Посмотри в мой kernel-image.git и покритикуй.
Времени это стоило вовсе немного, и ребэйзить эти бранчи
_мне_ тоже проще, чем если бы всё было в одном котле:
http://www.altlinux.org/Kernelnotes/mike

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

Я не про srpm, а про выделенность изменений не только topic
branch'ами, но и тематическими патчами.  Особенно если в бранче
накопилась уже борода патчей, которые никак не получается
пропихнуть в апстрим (или возможно, и никогда не получится,
как вот с отрыванием *.la).

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

Re: [devel] о культуре работы с git-репозиториями

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

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

On Sun, Jan 10, 2010 at 08:26:36PM +0200, Michael Shigorin wrote:

MS> Откуда они возьмутся, если желающие посмотрят на sisyphus.ru,
MS> git.altlinux.org, ужаснутся и пойдут дальше?

А с этого места подробнее, пожалуйста. Чему должны ужаснуться?

>> Думаю что аналогичный подход у большинства мантейнеров. 
MS> И он ужасен. :(

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

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

MS> Посмотри в мой kernel-image.git и покритикуй.
MS> Времени это стоило вовсе немного, и ребэйзить эти бранчи
MS> _мне_ тоже проще, чем если бы всё было в одном котле:
MS> http://www.altlinux.org/Kernelnotes/mike

Запустил git clone. Боюсь это не быстро будет :(

MS> Я не про srpm, а про выделенность изменений не только topic
MS> branch'ами, но и тематическими патчами.  

Термин "патч" относится к srpm, или я тебя не так понял?

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

У меня такое было, например, в zaptel. И мне было удобно держать все в
отдельных бранчах, да. Но именно на нем я пытался использовать схему с
"tarboll + патч". Чудесно, красиво, но когда надо хоть чуть-чуть
экспериментировать -- вместо "поправить строчку и дальше rpmbb" начинались
такие пляски с бубном, что мне стало страшно.

С тех пор у меня в srpm лежит в tarbol'е содержимое master. А вот патчики
по бранчам раскидывать -- таки да, очень ценно.

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

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


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

Re: [devel] о культуре работы с git-репозиториями

[Michael Shigorin]

On Sun, Jan 10, 2010 at 10:51:13PM +0300, Денис Смирнов wrote:
> MS> Откуда они возьмутся, если желающие посмотрят на sisyphus.ru,
> MS> git.altlinux.org, ужаснутся и пойдут дальше?
> А с этого места подробнее, пожалуйста. Чему должны ужаснуться?

Сравни:
http://sisyphus.ru/srpm/binutils/patches
http://sisyphus.ru/srpm/bash/patches
http://sisyphus.ru/srpm/evms/patches

> >> Думаю что аналогичный подход у большинства мантейнеров. 
> MS> И он ужасен. :(
> Увы, это реальность. Только не говори что у тебя море времени и
> ты идеально вылизываешь все свои пакеты, чтобы всем было удобно
> с ними работать.

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

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

А у меня сложное в srpm в основном пока.

> MS> Посмотри в мой kernel-image.git и покритикуй.
> MS> http://www.altlinux.org/Kernelnotes/mike
> Запустил git clone. Боюсь это не быстро будет :(

~/git/kernel-image> cat .gear/rules 
copy: config-*
diff: v2.6.27:. v2.6.27.42:. name=linux-2.6.27.42.patch
diff: v2.6.27.42:. fix-vm_deadlock:. name=fix-vm_deadlock.patch
diff: v2.6.27.42:. feat-fs-squashfs:. name=feat-fs-squashfs.patch

> MS> Я не про srpm, а про выделенность изменений не только topic
> MS> branch'ами, но и тематическими патчами.  
> Термин "патч" относится к srpm, или я тебя не так понял?

Имел в виду применительно к diff: в gear rules.
Можно ж бранчи помержить каскадом/пачкой и в мегапатч.

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

Re: [devel] о культуре работы с git-репозиториями

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

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

On Mon, Jan 11, 2010 at 02:11:04AM +0200, Michael Shigorin wrote:

MS> Сравни:
MS> http://sisyphus.ru/srpm/binutils/patches
MS> http://sisyphus.ru/srpm/bash/patches
MS> http://sisyphus.ru/srpm/evms/patches

Ой. Да, увы это теперь для многих пакетов устарело :(

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

Не обязательно тащить в git _красиво_. Тащить в стиле git-srpmimport по
крайней мере лучше чем собирать srpm, и при этом не будет проблем со
сложной структурой репозитория.

MS> ~/git/kernel-image> cat .gear/rules 
MS> copy: config-*
MS> diff: v2.6.27:. v2.6.27.42:. name=linux-2.6.27.42.patch
MS> diff: v2.6.27.42:. fix-vm_deadlock:. name=fix-vm_deadlock.patch
MS> diff: v2.6.27.42:. feat-fs-squashfs:. name=feat-fs-squashfs.patch

Это красиво, но:
1. Если патчи конфликтуют -- все, труба.
2. Если их много -- делать такое весьма геморно.
3. Если тебе нужно поправить пару строчек в патче и попробовать
пересобрать, как ты это будешь делать?

MS> Имел в виду применительно к diff: в gear rules.
MS> Можно ж бранчи помержить каскадом/пачкой и в мегапатч.

Понимаю. Выше проблемы, которые я не решил :(

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

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

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

Re: [devel] о культуре работы с git-репозиториями

[Michael Shigorin]

On Mon, Jan 11, 2010 at 07:57:22PM +0300, Денис Смирнов wrote:
> MS> copy: config-*
> MS> diff: v2.6.27:. v2.6.27.42:. name=linux-2.6.27.42.patch
> MS> diff: v2.6.27.42:. fix-vm_deadlock:. name=fix-vm_deadlock.patch
> MS> diff: v2.6.27.42:. feat-fs-squashfs:. name=feat-fs-squashfs.patch
> Это красиво, но:
> 1. Если патчи конфликтуют -- все, труба.

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

> 2. Если их много -- делать такое весьма геморно.

Зато можно %if'ить в спеке.

> 3. Если тебе нужно поправить пару строчек в патче и попробовать
> пересобрать, как ты это будешь делать?

Поправить пару строчек в бранче, закоммитить,
gear-update-tag -avc и пересобирать.

Собсно глянь ещё сюда, поразвесистей:
http://git.altlinux.org/people/led/packages/?p=kernel-image-2.6.27-tmc.git;a=summary
http://git.altlinux.org/people/led/packages/?p=kernel-image-2.6.27-tmc.git;a=blob;f=.gear/rules;h=6479b4bd69012d2dd6f5b4a2ce12add9ee70fa14;hb=55e0a1315dac487a354391b34bd9776c369a75ad

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

Re: [devel] о культуре работы с git-репозиториями

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

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

On Mon, Jan 11, 2010 at 07:18:27PM +0200, Michael Shigorin wrote:

MS> Не помню, где у меня такое водилось -- не перетаскивал.

У меня при работе над zaptel и asterisk было, увы :(

MS> Зато можно %if'ить в спеке.

Да, это очень большой плюс.

MS> Поправить пару строчек в бранче, закоммитить,
MS> gear-update-tag -avc и пересобирать.

Ты про merge с -s ours забыл. Итого:

git checkout <patchbranch>
(правим код)
git commit
git checkout master
git pull -s ours . <patchbranch>
gear-update-tag -avc
rpmbb <specname>


При работе по схеме upstream + master branches:
(правим код)
rpmbb <specname>

все!

Если генерится один большой патч, то добавляется только вызов
gear-update-tag.


MS> Собсно глянь ещё сюда, поразвесистей:
MS> http://git.altlinux.org/people/led/packages/?p=kernel-image-2.6.27-tmc.git;a=summary
MS> http://git.altlinux.org/people/led/packages/?p=kernel-image-2.6.27-tmc.git;a=blob;f=.gear/rules;h=6479b4bd69012d2dd6f5b4a2ce12add9ee70fa14;hb=55e0a1315dac487a354391b34bd9776c369a75ad

Жуть! Но для kernel пригодно в основном потому, что ты не хакаешь сам эти
патчи. Ты их в основном прикладываешь, и как раз основные манипуляции с
ними при тестах -- ifdef.

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

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

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

Re: [devel] о культуре работы с git-репозиториями

[Led]

On Tuesday, 12 January 2010 18:19:52 Денис Смирнов wrote:
> On Mon, Jan 11, 2010 at 07:18:27PM +0200, Michael Shigorin wrote:
>
> MS> Не помню, где у меня такое водилось -- не перетаскивал.
>
> У меня при работе над zaptel и asterisk было, увы :(
>
> MS> Зато можно %if'ить в спеке.
>
> Да, это очень большой плюс.
>
> MS> Поправить пару строчек в бранче, закоммитить,
> MS> gear-update-tag -avc и пересобирать.
>
> Ты про merge с -s ours забыл. Итого:
>
> git checkout <patchbranch>
> (правим код)
> git commit
> git checkout master
> git pull -s ours . <patchbranch>
> gear-update-tag -avc
> rpmbb <specname>
>
>
> При работе по схеме upstream + master branches:
> (правим код)
> rpmbb <specname>
>
> все!

Вот здесь - полностью согласен. Действительно - "всё!"... тушите свет...

>
> Если генерится один большой патч, то добавляется только вызов
> gear-update-tag.
>
>
> MS> Собсно глянь ещё сюда, поразвесистей:
> MS>
> http://git.altlinux.org/people/led/packages/?p=kernel-image-2.6.27-tmc.git;
>a=summary MS>
> http://git.altlinux.org/people/led/packages/?p=kernel-image-2.6.27-tmc.git;
>a=blob;f=.gear/rules;h=6479b4bd69012d2dd6f5b4a2ce12add9ee70fa14;hb=55e0a1315
>dac487a354391b34bd9776c369a75ad
>
> Жуть! Но для kernel пригодно в основном потому, что ты не хакаешь сам эти
> патчи. Ты их в основном прикладываешь, и как раз основные манипуляции с
> ними при тестах -- ifdef.

Ваша телепатия дала сбой. Там так ИМЕННО потому, что почти над всеми 
бранчами - работают, а не "просто прикладывают"

-- 
Led

Re: [devel] о культуре работы с git-репозиториями

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

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

On Wed, Jan 13, 2010 at 12:04:32AM +0200, Led wrote:

>> При работе по схеме upstream + master branches:
>> (правим код)
>> rpmbb <specname>
>> все!
L> Вот здесь - полностью согласен. Действительно - "всё!"... тушите свет...

Зачем тушить свет? Собранный пакет тестить, а уж когда итерации
издевательства над пакетом закончатся, тогда уж править spec, ставить тэг,
отправлять на сборку. Что тебе не нравится?

L> Ваша телепатия дала сбой. Там так ИМЕННО потому, что почти над всеми 
L> бранчами - работают, а не "просто прикладывают"

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

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

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

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

Re: [devel] о культуре работы с git-репозиториями

[Alexey Morozov]

Здравствуйте.

В сообщении от 11 января 2010 22:57:22 автор Денис Смирнов написал:

> Это красиво, но:
> 1. Если патчи конфликтуют -- все, труба.
> 2. Если их много -- делать такое весьма геморно.
Возможно, ответом на два этих пункта являются 
quit - http://savannah.nongnu.org/projects/quilt
stgit - http://procode.org/stgit/
или topgit - http://repo.or.cz/w/topgit.git/blob_plain/341a3713f5c399f97c5c68a74772b12bb3d2ca57:/README

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

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

> 3. Если тебе нужно поправить пару строчек в патче и попробовать
> пересобрать, как ты это будешь делать?
Хых, "...и один емакс, чтобы править ими всеми". А если серьёзно, то,
в зависимости от тяжести правок можно либо подправить патч, либо
приложить его, подправить исходники и потом сгенерировать новый.
В общем, всё зависит от задачи.

С уважением,
Алексей Морозов

Re: [devel] о культуре работы с git-репозиториями (was: [SCM] packages/qemu: heads/master)

[Dmitry V. Levin]

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

On Sun, Jan 10, 2010 at 04:32:48PM +0300, Afanasov Dmitry wrote:
> On Sun, Jan 10, 2010 at 04:11:59PM +0300, Денис Смирнов wrote:
> > On Sun, Jan 10, 2010 at 01:32:54PM +0200, Michael Shigorin wrote:
> > 
> > MS> Меня вот тошнит от мегапатча или вообще бухнутого в тарбол
> > MS> master, в котором леший ногу сломит -- у тебя таких гитов
> > MS> довольно много, а между тем srpm с разложенными патчами куда
> > MS> дружественней и уважительней по отношению к другим, чем такое.
> > 
> > Миш, тут такая тема -- как мы относимся к srpm. Сейчас к srpm
> > "официальное" отношение, что это просто промежуточный формат для сборки.
> что я считаю бредом. пока у gear не будет зависимостей, пока apt-get
> source не поставит нужную репу, пока не появится новый gear package
> manager, gear будет не более чем хранилищем, а результатом будет всё
> тот же srpm.
> 
> srpm не промежуточный формат, srpm - результат. хехе, hasher и тот
> зависимости вычисляет через rpmquery -qR <srpm>.
> 
> > С этой точки зрения не важно в каком виде результат плюхается в srpm, но
> > важно насколько удобно работать с чужим git-репозиторием.
> важно - готовый патч проще взять и приложить, чем взять репу и вычислять,
> откуда что растет.
> 
> /me представить страшно, если на packages.<distr>.org перестанут как у нас
> выкладывать патчи.
> 
> > Првада раскладывать по файликам полезно с другой точки зрения.
> кажись именно её я и озвучил :)
> 
> > У нас нет централизованного хранилица git repo, как это ни парадоксально
> > звучит. Скажем nginx сейчас собирают несколько человек, вопрос -- какой
> > repo можно считать "основным" ?
> да-да-да, буквально рядом отписался о том же.
> 
> я даже более вопрос ставлю: структура git такова, что после каждого clone
> мы получаем новый репозитарий со своей историей. видно это тогда, когда
> репозитарии на работе, дома и на git.alt рассинхронизируются - в этом
> случае мы получаем merge с раздвоением истории.
> 
> проще говоря: каждая репа - это новый бранч.

Либо вы не понимаете, как устроен git, либо вам не удалось донести свою
мысль.  Попробуйте переформулировать то, что вы написали.


-- 
ldv

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

Re: [devel] о культуре работы с git-репозиториями (was: [SCM] packages/qemu: heads/master)

[Afanasov Dmitry]

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

On Sun, Jan 10, 2010 at 07:08:47PM +0300, Dmitry V. Levin wrote:
> On Sun, Jan 10, 2010 at 04:32:48PM +0300, Afanasov Dmitry wrote:
> > On Sun, Jan 10, 2010 at 04:11:59PM +0300, Денис Смирнов wrote:
> > > Миш, тут такая тема -- как мы относимся к srpm. Сейчас к srpm
> > > "официальное" отношение, что это просто промежуточный формат для сборки.
> > srpm не промежуточный формат, srpm - результат.
[...]
> > проще говоря: каждая репа - это новый бранч.
> 
> Либо вы не понимаете, как устроен git, либо вам не удалось донести свою
> мысль. 
не удалось донести мысль.

On Sun, Jan 10, 2010 at 07:01:04PM +0300, Денис Смирнов wrote:
> AD> кажись именно её я и озвучил :)
> Возможно я не понял :)
точно не удалось :)

On Sun, Jan 10, 2010 at 07:08:47PM +0300, Dmitry V. Levin wrote:
> Попробуйте переформулировать то, что вы написали.
пробовали уже, хотя и не по git. и тогда от вас поступил такой же текст.

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

прошу прощения у сommunity за очередной философский приступ.

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

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

Re: [devel] [jt] о культуре

[Dmitry V. Levin]

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

On Sun, Jan 10, 2010 at 08:04:21PM +0300, Afanasov Dmitry wrote:
> On Sun, Jan 10, 2010 at 07:08:47PM +0300, Dmitry V. Levin wrote:
> > Попробуйте переформулировать то, что вы написали.
> пробовали уже, хотя и не по git. и тогда от вас поступил такой же текст.

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


-- 
ldv

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

Re: [devel] [jt] о культуре

[Afanasov Dmitry]

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

On Sun, Jan 10, 2010 at 08:09:01PM +0300, Dmitry V. Levin wrote:
> On Sun, Jan 10, 2010 at 08:04:21PM +0300, Afanasov Dmitry wrote:
> > On Sun, Jan 10, 2010 at 07:08:47PM +0300, Dmitry V. Levin wrote:
> > > Попробуйте переформулировать то, что вы написали.
> > пробовали уже, хотя и не по git. и тогда от вас поступил такой же текст.
> 
> Если не будете пробовать, то гарантированно не получите тот результат,
> на который рассчитываете.  Попробуйте читать весь свой текст целиком
> перед отправкой.
хорошо, попробую.

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

в случае с графом source rpm являются листьями.

gear этим фундаментальным свойством - зависимостями - не обладает. и это
его главный недостаток, мешающий воспринимать его как основу для binary
rpm пакета. одна из причин: хотя gear и хранит в себе spec, нет
фиксированого бранча, откуда его брать. нет фиксированного коммита, откуда
его брать.

вторая причина - отсутсвие утилит. для работы rpm и source rpm есть
rpmquery и apt-get, для gear'а есть только "rpmbuild".

потому с фразой:

On Sun, Jan 10, 2010 at 04:11:59PM +0300, Денис Смирнов wrote:
> Сейчас к srpm "официальное" отношение, что это просто промежуточный
> формат для сборки.

я не согласен. source rpm пристуствовать обязан и он не является
промежуточным форматом.

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

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

Re: [devel] о репозиториях и об исходных пакетах

[Dmitry V. Levin]

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

On Sun, Jan 10, 2010 at 08:44:20PM +0300, Afanasov Dmitry wrote:
> On Sun, Jan 10, 2010 at 08:09:01PM +0300, Dmitry V. Levin wrote:
> > On Sun, Jan 10, 2010 at 08:04:21PM +0300, Afanasov Dmitry wrote:
> > > On Sun, Jan 10, 2010 at 07:08:47PM +0300, Dmitry V. Levin wrote:
> > > > Попробуйте переформулировать то, что вы написали.
> > > пробовали уже, хотя и не по git. и тогда от вас поступил такой же текст.
> > 
> > Если не будете пробовать, то гарантированно не получите тот результат,
> > на который рассчитываете.  Попробуйте читать весь свой текст целиком
> > перед отправкой.
> хорошо, попробую.
> 
> в моём представлении репозитарий является сочетанием двух множеств -
> множества бинарных пакетов и исходников. основной чертой репозитария
> являются зависимости, благодаря которым он приобретает свойства
> упорядоченности и замкнутости, или связанности и направленности, если
> воспринимать репозитарий как граф.
> 
> в случае с графом source rpm являются листьями.

Почему?

> gear этим фундаментальным свойством - зависимостями - не обладает. и это
> его главный недостаток, мешающий воспринимать его как основу для binary
> rpm пакета. одна из причин: хотя gear и хранит в себе spec, нет
> фиксированого бранча, откуда его брать. нет фиксированного коммита, откуда
> его брать.

Зависимости srpm-пакетов -- это функция от исходного кода и сборочной
среды.  Такова идеология rpmbuild: сборочные зависимости вычисляются во
время сборки.  Таким образом, если попробовать перенести эту модель
непосредственно на исходный код (gear-репозиторий), то для сохранения
нынешнего функционала пришлось бы реализовать вычисление зависимостей.
Вопрос, зачем дублировать функционал rpmbuild?

> вторая причина - отсутсвие утилит. для работы rpm и source rpm есть
> rpmquery и apt-get, для gear'а есть только "rpmbuild".

Для gear есть весь инструментарий git, hasher и rpmbuild.
Поясните, пожалуйста, на примерах, утилиты какого рода вам нужны.

> потому с фразой:
> 
> On Sun, Jan 10, 2010 at 04:11:59PM +0300, Денис Смирнов wrote:
> > Сейчас к srpm "официальное" отношение, что это просто промежуточный
> > формат для сборки.
> 
> я не согласен. source rpm пристуствовать обязан и он не является
> промежуточным форматом.

Он уже сейчас фактически является промежуточным форматом.  Более того,
для некоторых моих пакетов (например, там, где используется директива
"tar: ."), полученные srpm-файлы, строго говоря, не удовлетворяют
требованиям GPL к предоставляемому исходному коду, в то время как
git-репозитории, из которых эти srpm-файлы были собраны, этим требованиям
удовлетворяют.


-- 
ldv

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

Re: [devel] о репозиториях и об исходных пакетах

[Afanasov Dmitry]

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

On Sun, Jan 10, 2010 at 10:30:04PM +0300, Dmitry V. Levin wrote:
> On Sun, Jan 10, 2010 at 08:44:20PM +0300, Afanasov Dmitry wrote:
> > в моём представлении репозитарий является сочетанием двух множеств -
> > множества бинарных пакетов и исходников. основной чертой репозитария
> > являются зависимости, благодаря которым он приобретает свойства
> > упорядоченности и замкнутости, или связанности и направленности, если
> > воспринимать репозитарий как граф.
> > 
> > в случае с графом source rpm являются листьями.
> 
> Почему?
зависимости прописываются в каждый rpm пакет: как source, так и binary. за
исключением того, что в source rpm прописаны только requires.

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

кажется, данные о производных binary rpm даже хранятся в кеше apt'а, что
позволяет вычислить эти provides с точностью до имени srpm пакета. по
крайней мере perl'ом я их как-от выковыривал.

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

> Зависимости srpm-пакетов -- это функция от исходного кода и сборочной
> среды.  Такова идеология rpmbuild: сборочные зависимости вычисляются во
> время сборки.
спорил сам с собой, спорил, и пришёл к выводу, что такое определение
верно.

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

хотя если обойтись без hasher'а, то при неудовлетворенной зависимости мы
получим облом, а никакие ни вычисления, а значит это всё-таки идиология
hasher'а :)

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

более того, если вспомнить первый вопрос о листьях в графе - если srpm
является листьями в графе, если мы имеем информацию о srpm в кеше апта
либо имеем целиком каталог Sisyphus, то мы можем, исходя из зависимостей,
построить граф кто из кого собрался. не имея srpm мы этот граф построить не
можем, как как наши git'ы не являются частью репозитария.

> Вопрос, зачем дублировать функционал rpmbuild?
gear и так дублирует его функционал в части сборки (упомянутый мной
rpmbuild). почему бы не продублировать в части rpmquery? :)

> > вторая причина - отсутсвие утилит. для работы rpm и source rpm есть
> > rpmquery и apt-get, для gear'а есть только "rpmbuild".
> 
> Для gear есть весь инструментарий git, hasher и rpmbuild.
> Поясните, пожалуйста, на примерах, утилиты какого рода вам нужны.
gear-query для запросов данных из spec; apt-get gear для получения gear
репозитария, откуда собран пакет; данные о gear'ах, из которых собраны
пакеты, в кеше апта; каталог gears в Sisyphus.

смех смехом, а от gear-query-requires я б действительно не отказался.
хотя да, виноват, всё руки из hasher'а выгрызть этот код не доходят.

> > я не согласен. source rpm пристуствовать обязан и он не является
> > промежуточным форматом.
> 
> Он уже сейчас фактически является промежуточным форматом.
нет, пока данных в репозитарии недостаточно для получение нужного
gear'репы, srpm не будет промежуточным форматом, а значит srpm'ы должны
быть как минимум внятно оформлены.

и если srpm не соответсвтует GPL, значит надо собирать так, чтобы
соотвествовали. либо копировать gears/ в Sisyphus/, обучать apt с ними
работать и удалять SRPMS нафиг.

и ещё учесть, что srpm весит много меньше, чем gear, содержащий 10к
srpm'ов за последние N лет.

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

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

Re: [devel] о репозиториях и об исходных пакетах

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

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

On Mon, Jan 11, 2010 at 12:01:27AM +0300, Afanasov Dmitry wrote:

AD> gear и так дублирует его функционал в части сборки (упомянутый мной
AD> rpmbuild). почему бы не продублировать в части rpmquery? :)

Каким местом он его дублирует?

AD> gear-query для запросов данных из spec; apt-get gear для получения gear
AD> репозитария, откуда собран пакет; данные о gear'ах, из которых собраны
AD> пакеты, в кеше апта; каталог gears в Sisyphus.
AD> смех смехом, а от gear-query-requires я б действительно не отказался.
AD> хотя да, виноват, всё руки из hasher'а выгрызть этот код не доходят.

Это процедура нетривиальная. Для этого создается chroot, помещается туда
минимальный набор пакетов, туда же кладутся BuildPreReq из spec'а. После
чего уже внутри этого чрута с помощью rpmbuild можно получить этот список.

AD> нет, пока данных в репозитарии недостаточно для получение нужного
AD> gear'репы, 

Их уже прямо сейчас достаточно. Приведите конкретную задачу (не
абстрактную) и я покажу как ее решать.

AD> srpm не будет промежуточным форматом, а значит srpm'ы должны
AD> быть как минимум внятно оформлены.
AD> и если srpm не соответсвтует GPL, значит надо собирать так, чтобы
AD> соотвествовали. 

Кому надо?

AD> либо копировать gears/ в Sisyphus/, обучать apt с ними
AD> работать и удалять SRPMS нафиг.
AD> и ещё учесть, что srpm весит много меньше, чем gear, содержащий 10к
AD> srpm'ов за последние N лет.

Да, это так. Однако для большинства пакетов (кроме тех где multimedia и
прочие данные) git репо занимает часто на _порядки_ меньше места чем
архив src.rpm за длительный период (а иметь историю полезно).

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

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

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

Re: [devel] [jt] о культуре

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

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

On Sun, Jan 10, 2010 at 08:44:20PM +0300, Afanasov Dmitry wrote:

AD> gear этим фундаментальным свойством - зависимостями - не обладает. и

Обладает почти в той же мере, что и srpm. Ибо внутри gear repo лежит spec,
в котором указаны зависимости.

Есть правда тонкости (зависимости внутри srpm зависят от окружения, в
котором собирается этот srpm), но в целом зависимости есть -- ибо
прописаны в spec'е.

AD> это
AD> его главный недостаток, мешающий воспринимать его как основу для binary
AD> rpm пакета. 

Да, и именно поэтому для hasher используется промежуточный формат -- srpm.

AD> одна из причин: хотя gear и хранит в себе spec, нет
AD> фиксированого бранча, откуда его брать. нет фиксированного коммита, откуда
AD> его брать.

На сборку отправляется как раз фиксированный коммит -- подписанный tag.

AD> вторая причина - отсутсвие утилит. для работы rpm и source rpm есть
AD> rpmquery и apt-get, для gear'а есть только "rpmbuild".

Брррр. apt-get не работает с srpm. За исключением apt-get source и apt-get
build-dep, причем второй работает тоже не с srpm а с базой данных.

AD> я не согласен. source rpm пристуствовать обязан и он не является
AD> промежуточным форматом.

Можно список разных workflow в которых нужен сам srpm, как отдельный
имеющий самостоятельную значимость объект, а не как промежуточный формат
между gear repo и hasher?


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

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

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

Re: [devel] [jt] о культуре

[Max Ivanov]

> Обладает почти в той же мере, что и srpm. Ибо внутри gear repo лежит spec,
> в котором указаны зависимости.
>
> Есть правда тонкости (зависимости внутри srpm зависят от окружения, в
> котором собирается этот srpm), но в целом зависимости есть -- ибо
> прописаны в spec'е.

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

Re: [devel] [jt] о культуре

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

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

On Sun, Jan 10, 2010 at 08:25:53PM +0000, Max Ivanov wrote:

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

Для сборки одного пакета нужен один единственный gear-repo.

Пожалуйста, переформулируйте вашу просьбу в виде конкретного usecase.

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

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

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

Re: [devel] [jt] о культуре

[Afanasov Dmitry]

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

On Sun, Jan 10, 2010 at 11:05:04PM +0300, Денис Смирнов wrote:
> On Sun, Jan 10, 2010 at 08:44:20PM +0300, Afanasov Dmitry wrote:
> 
> AD> gear этим фундаментальным свойством - зависимостями - не обладает. и
> 
> Обладает почти в той же мере, что и srpm. Ибо внутри gear repo лежит spec,
> в котором указаны зависимости.

и далее:
> На сборку отправляется как раз фиксированный коммит -- подписанный tag.

я всё-таки повторюсь: 
> AD> одна из причин: хотя gear и хранит в себе spec, нет фиксированого
> AD> бранча, откуда его брать. нет фиксированного коммита, откуда его
> AD> брать.

здесь уже поднимали вопрос о прописывании коммита в rpm, из которого он
вырос. до тех пор, пока данных об этом коммите не будет в самом
репозаитарии (каталог Sisyphus), а не где-то на серверах git.alt,
автоматически выдрать весь gear не получится. максимум, что получится -
получить коммит из /gears. я же веду речь о репозитариях из /people,
откуда всё и растёт.

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

> Есть правда тонкости (зависимости внутри srpm зависят от окружения, в
> котором собирается этот srpm), но в целом зависимости есть -- ибо
> прописаны в spec'е.
я кажется действительно что-то не понимаю. окружение же строится исходя из
зависимостей, почему вы считаете, что наоборот? из-за buildreq? 

> AD> это
> AD> его главный недостаток, мешающий воспринимать его как основу для binary
> AD> rpm пакета. 
> 
> Да, и именно поэтому для hasher используется промежуточный формат -- srpm.
вот, кстати, hasher'у на srpm плевать - он там используется только в рамках
повторного использования кода rpmbuild. будет свой парсер spec, и srpm
для hasher'а будет не нужен.

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

> AD> вторая причина - отсутсвие утилит. для работы rpm и source rpm есть
> AD> rpmquery и apt-get, для gear'а есть только "rpmbuild".
> 
> Брррр. apt-get не работает с srpm. За исключением apt-get source и apt-get
> build-dep, причем второй работает тоже не с srpm а с базой данных.
да, apt-get всюду работает с базой данных, как rpm так и srpm он дергает
только на этапе установки.

с srpm работает genbasedir, что генерирует эту базу, с которой работает
apt-get. и genbasedir ничерта не знает про gear и его таги.

засим аргумент не принят :)

> AD> я не согласен. source rpm пристуствовать обязан и он не является
> AD> промежуточным форматом.
> 
> Можно список разных workflow в которых нужен сам srpm, как отдельный
> имеющий самостоятельную значимость объект, а не как промежуточный формат
> между gear repo и hasher?
repocop, sisyphus_check, sisyphus.ru, удаление пакета из репозитария
вместе с порожденными binary rpm, вычисление списка бинарных пакетов,
собираемых из данного srpm.

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

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

Re: [devel] [jt] о культуре

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

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

On Mon, Jan 11, 2010 at 12:28:11AM +0300, Afanasov Dmitry wrote:

[skip]

Это все философия, а у нас тут devel@ :)

Я предлагаю вместо общих слов кто там является пакетным менеджером, а кто
некатегоризируемым инструментарием, исходить из use cases, и того решаются
ли они, или нет.

Иначе получается каша в головах.

AD> здесь уже поднимали вопрос о прописывании коммита в rpm, из которого он
AD> вырос. до тех пор, пока данных об этом коммите не будет в самом
AD> репозаитарии (каталог Sisyphus), а не где-то на серверах git.alt,
AD> автоматически выдрать весь gear не получится. максимум, что получится -
AD> получить коммит из /gears. 

Ага. А с ftp взять весь srpm не получится, получится взять только файлик с
расширением .src.rpm. А вдруг у него есть еще какие-то части, которые не
выложены? Например при скачивании по http потеряются права доступа,
которые были выданы этому файлу! А еще там ведь могли быть extended
attributes. Кошмар-кошмар! src.rpm не работает! Всем бояться.

AD> я же веду речь о репозитариях из /people, откуда всё и растёт.

В таком случае я буду утверждать что src.rpm фигня, ибо у меня нет доступа
к личному компьютеру ldv@, из которого растет glibc. Если нет доступа к
glibc, то какой это тогда вообще дистрибутив?

Перевожу: есть git.alt/gears. Там содержится фактически столько же
информации сколько в лежащем в Сизифе файлике src.rpm.

AD> так что нет, не в той же мере. один gear хранит в себе множество srpm, что
AD> поднимает проблему поиска и выбора, где же там нужный нам коммит.

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

Поясняю -- src.rpm  это всего лишь срез. Точно такой же как tag.

А теперь сформулируй свои красивые слова не в виде сложностей каких-то, а
в виде задачи которую легко решить с помощью src.rpm, и сложно -- с
помощью gear.

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

Hint: макросы. Т.е. я могу написать в spec:
BuildPreReq: supermacro-package
BuildRequires: %supermacro

И тогда сборочная зависимость у src.rpm будет невычисляема до установки в
chroot supermacro-packages, засовывания туда spec'а и выполнения таки
rpmbuild -bs уже в этом chroot.

Благо gear все это делает за нас. Но да, это приводит к тому что из одного
spec'а теоретически можно получить два разных src.rpm. Хотя бы потому что
макрос может раскрыться вообще в полспека :)

AD> вот, кстати, hasher'у на srpm плевать - он там используется только в рамках
AD> повторного использования кода rpmbuild. будет свой парсер spec, и srpm
AD> для hasher'а будет не нужен.
AD> останется только добавить gears в сам репозитарий и тогда я соглашусь, что
AD> технически srpm не нужен.

Что такое "добавить gears в сам репозитарий"?

AD> да, apt-get всюду работает с базой данных, как rpm так и srpm он дергает
AD> только на этапе установки.
AD> с srpm работает genbasedir, что генерирует эту базу, с которой работает
AD> apt-get. и genbasedir ничерта не знает про gear и его таги.
AD> засим аргумент не принят :)

Итак, src.rpm и тут является лишь промежуточным форматом, самостоятельной
ценности не имеющим.

>> Можно список разных workflow в которых нужен сам srpm, как отдельный
>> имеющий самостоятельную значимость объект, а не как промежуточный формат
>> между gear repo и hasher?
AD> repocop, sisyphus_check, sisyphus.ru, удаление пакета из репозитария
AD> вместе с порожденными binary rpm, вычисление списка бинарных пакетов,
AD> собираемых из данного srpm.

Во-первых это не workflow, а также подзадачи внутри workflow.
Во-вторых во всех их src.rpm нужен на коротком временном интервале, и не
представляет ценности как объект.

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

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

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

Re: [devel] о культуре работы с git-репозиториями

[Aleksey Avdeev]

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

10.01.2010 16:32, Afanasov Dmitry пишет:
> On Sun, Jan 10, 2010 at 04:11:59PM +0300, Денис Смирнов wrote:
...
>> С этой точки зрения не важно в каком виде результат плюхается в srpm, но
>> важно насколько удобно работать с чужим git-репозиторием.
> важно - готовый патч проще взять и приложить, чем взять репу и вычислять,
> откуда что растет.

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

> 
> /me представить страшно, если на packages.<distr>.org перестанут как у нас
> выкладывать патчи.
> 
>> Првада раскладывать по файликам полезно с другой точки зрения.
> кажись именно её я и озвучил :)
> 
>> У нас нет централизованного хранилица git repo, как это ни парадоксально
>> звучит. Скажем nginx сейчас собирают несколько человек, вопрос -- какой
>> repo можно считать "основным" ?
> да-да-да, буквально рядом отписался о том же.

-- 

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



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

Re: [devel] о культуре работы с git-репозиториями

[Slava Semushin]

11 января 2010 г. 22:04 пользователь Aleksey Avdeev <solo@solin.spb.ru> написал:
[...]
>  Именно поэтому я и отстаиваю идею поддержку разработки разных вещей в
> разных бранчах, с последующим сведением с помощью мержей: такой
> репозиторий проще анализировать, чем тот где работа ведётся в одном бранче.

Не знаю что там с новичками, но когда начинаются бранчи и мержи, то
для меня это уже сложновато. Вот схема как после gear-srpmimport-а,
мне ясна и понятна, а с этими бранчами.

Хотел в своё время обновить diffstat (#19890, баг с мая висит), но там
заморочки с бранчами и прочими подобными вещами. Вроде идея ясна, но
не полностью, так что использовать что-то не до конца ясное не
хочется. Так баг и не закрыт, между прочим.

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

Были два NMU flawfinder-а от bga@ и real@. Сейчас не могу смержиться
без конфликтов, потому что там откуда-то .gear/tags/list появился
какой-то и файл .gear-rules переименовывали, хотя вроде бы должна была
быть простая пересборка.

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

-- 
Slava Semushin

Re: [devel] о культуре работы с git-репозиториями

[Aleksey Avdeev]

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

11.01.2010 19:31, Slava Semushin пишет:
> 11 января 2010 г. 22:04 пользователь Aleksey Avdeev <solo@solin.spb.ru> написал:
> [...]
>>  Именно поэтому я и отстаиваю идею поддержку разработки разных вещей в
>> разных бранчах, с последующим сведением с помощью мержей: такой
>> репозиторий проще анализировать, чем тот где работа ведётся в одном бранче.
> 
> Не знаю что там с новичками, но когда начинаются бранчи и мержи, то
> для меня это уже сложновато. Вот схема как после gear-srpmimport-а,
> мне ясна и понятна, а с этими бранчами.

  Я с репозиториями с помощью gitk --all работаю: он позволяет
достаточно просто анализировать отдельные бранчи (и/или их фрагменты).
Если же все изменения в одном бранче -- приходится каждый раз
фальтровать коммиты на тему относятся ли они к анализируемым в данный
момент.

...
> 
> Были два NMU flawfinder-а от bga@ и real@. Сейчас не могу смержиться
> без конфликтов, потому что там откуда-то .gear/tags/list появился
> какой-то и файл .gear-rules переименовывали, хотя вроде бы должна была
> быть простая пересборка.

  .gear/tags/list -- это результат работы gear-update-tag (создаётся
данной утилитой автоматически, нужен для фиксации использованных
тегов/бранчей).

  .gear/rules -- это новое место для .gear-rules (старый вариант
поддерживается для совместимости).

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

-- 

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



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

Re: [devel] о культуре работы с git-репозиториями

[Michael Shigorin]

On Mon, Jan 11, 2010 at 07:42:27PM +0300, Aleksey Avdeev wrote:
> .gear/tags/list -- это результат работы gear-update-tag
> (создаётся данной утилитой автоматически, нужен для фиксации
> использованных тегов/бранчей).

...по ссылкам из .gear/rules

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

Re: [devel] о культуре работы с git-репозиториями

[Dmitry V. Levin]

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

On Sun, Jan 10, 2010 at 04:11:59PM +0300, Денис Смирнов wrote:
[...]
> У нас нет централизованного хранилица git repo, как это ни парадоксально
> звучит. Скажем nginx сейчас собирают несколько человек, вопрос -- какой
> repo можно считать "основным" ?
> 
> По идее -- это git.alt/gears/n/nginx. Но вот в чем проблема -- этот репо
> содержит исключительно тот бранч, что в моем репо именуется 'master'. А,
> например, того бранча, который у меня называется 'upstream' там нет.

Там есть все коммиты бранча upstream, следовательно, можно _автоматически_
восстановить бранч upstream по истории Merge branch 'upstream'.

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


-- 
ldv

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

Re: [devel] о культуре работы с git-репозиториями

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

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

On Sun, Jan 10, 2010 at 08:44:14PM +0300, Dmitry V. Levin wrote:

DVL> Там есть все коммиты бранча upstream, следовательно, можно _автоматически_
DVL> восстановить бранч upstream по истории Merge branch 'upstream'.

Вот смотрю я на такой commit. Как из него получить id commit'а из того
самого upstream, да еще и отличить его от master?

DVL> Хотя, конечно, бывает всякое.  Вспомни, с чего эта тема начиналась.
DVL> Так же и с исходным кодом: бывает, распакуешь тарбол, заглянешь внутрь, а
DVL> там такое, такое!...

:)

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

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

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

Re: [devel] о культуре работы с git-репозиториями

[Dmitry V. Levin]

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

On Sun, Jan 10, 2010 at 10:44:34PM +0300, Денис Смирнов wrote:
> On Sun, Jan 10, 2010 at 08:44:14PM +0300, Dmitry V. Levin wrote:
> 
> DVL> Там есть все коммиты бранча upstream, следовательно, можно _автоматически_
> DVL> восстановить бранч upstream по истории Merge branch 'upstream'.
> 
> Вот смотрю я на такой commit. Как из него получить id commit'а из того
> самого upstream, да еще и отличить его от master?

В строке
Merge: 7ba71c8 a59ebcd
первым указан old master, вторым -- upstream.


-- 
ldv

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

Re: [devel] о культуре работы с git-репозиториями

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

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

On Sun, Jan 10, 2010 at 10:48:47PM +0300, Dmitry V. Levin wrote:

DVL> В строке
DVL> Merge: 7ba71c8 a59ebcd
DVL> первым указан old master, вторым -- upstream.

Это в tig я увидел, а как это средствами git получить да с полными commit
id?


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

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

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

Re: [devel] о культуре работы с git-репозиториями

[Dmitry V. Levin]

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

On Sun, Jan 10, 2010 at 11:06:34PM +0300, Денис Смирнов wrote:
> On Sun, Jan 10, 2010 at 10:48:47PM +0300, Dmitry V. Levin wrote:
> 
> DVL> В строке
> DVL> Merge: 7ba71c8 a59ebcd
> DVL> первым указан old master, вторым -- upstream.
> 
> Это в tig я увидел, а как это средствами git получить да с полными commit
> id?

Есть много альтернативных вариантов достичь желаемого.
Например, у git-log есть параметр --format.


-- 
ldv

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

Re: [devel] о культуре работы с git-репозиториями

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

[-- Attachment #1.1: Type: text/plain, Size: 361 bytes --]

On Sun, Jan 10, 2010 at 11:47:37PM +0300, Dmitry V. Levin wrote:

DVL> Есть много альтернативных вариантов достичь желаемого.
DVL> Например, у git-log есть параметр --format.

Вроде нечто делающее вид что работает написал. 

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

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

[-- Attachment #1.2: git-autobranches --]
[-- Type: text/plain, Size: 320 bytes --]

#!/usr/bin/perl -w
use strict;

open( IN, "git log --merges --format=\"%P %s\" |" ) || die;

my %branches;

while (<IN>) {
    /^([0-9a-f]+)\s([0-9a-f]+)\sMerge branch '(.+?)'/ || next;
    $branches{$3} = $2 unless defined $branches{$3};
}

close(IN);

print $_. " " . $branches{$_} . "\n" foreach sort keys %branches;

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

Re: [devel] о культуре работы с git-репозиториями (was: [SCM] packages/qemu: heads/master)

[Afanasov Dmitry]

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

On Sun, Jan 10, 2010 at 01:32:54PM +0200, Michael Shigorin wrote:
> On Sun, Jan 10, 2010 at 04:08:13AM +0300, Dmitry V. Levin wrote:
> > > PS: Я не настаиваю именно на своём варианте:
> > Однако вы настаиваете на своём методе, который по сути есть ни
> > что иное как графо^Wгитоманство и перевод чернил^Wкоммитов.
> > Грустно смотреть, на что порой расходуют себя умные люди.
> 
> Меня вот тошнит от мегапатча или вообще бухнутого в тарбол
> master, в котором леший ногу сломит -- у тебя таких гитов
> довольно много, а между тем srpm с разложенными патчами куда
> дружественней и уважительней по отношению к другим, чем такое.
кроме +1 добавлю -s ours, который проверки на непрерывность истории
превращает в издевательство; постоянные вычисления к какому
же бранчу относятся ветки истории и какого ляда его переименовали.

> Надо вылизывать и документировать разные workflow.
> И не только из соображений удобства себя любимого,
> здесь и сейчас.
я тут ещё головной боли придумал - привязать одного gear репу к пакету и
выдавать acl не просто на сборку, на на push в репу. а то расплодили тут
репозитариев, NMU замучаешься собирать. а историю проверять hook'ами в
git'е.
-- 
С уважением
Афанасов Дмитрий

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

Re: [devel] о культуре работы с git-репозиториями (was: [SCM] packages/qemu: heads/master)

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

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

On Sun, Jan 10, 2010 at 04:19:57PM +0300, Afanasov Dmitry wrote:

AD> кроме +1 добавлю -s ours, который проверки на непрерывность истории
AD> превращает в издевательство; постоянные вычисления к какому
AD> же бранчу относятся ветки истории и какого ляда его переименовали.

Какие есть предложения по решению этой проблемы?

AD> я тут ещё головной боли придумал - привязать одного gear репу к пакету и
AD> выдавать acl не просто на сборку, на на push в репу. а то расплодили тут
AD> репозитариев, NMU замучаешься собирать. а историю проверять hook'ами в
AD> git'е.

man git-config на предмет pushNonFastForward


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

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

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

Re: [devel] о культуре работы с git-репозиториями (was: [SCM] packages/qemu: heads/master)

[Afanasov Dmitry]

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

On Sun, Jan 10, 2010 at 06:43:00PM +0300, Денис Смирнов wrote:
> On Sun, Jan 10, 2010 at 04:19:57PM +0300, Afanasov Dmitry wrote:
> 
> AD> кроме +1 добавлю -s ours, который проверки на непрерывность истории
> AD> превращает в издевательство; постоянные вычисления к какому
> AD> же бранчу относятся ветки истории и какого ляда его переименовали.
> 
> Какие есть предложения по решению этой проблемы?
быть проще :) а также позволять себе отказываться от истории.

> AD> я тут ещё головной боли придумал - привязать одного gear репу к пакету и
> AD> выдавать acl не просто на сборку, на на push в репу. а то расплодили тут
> AD> репозитариев, NMU замучаешься собирать. а историю проверять hook'ами в
> AD> git'е.
> 
> man git-config на предмет pushNonFastForward
кстати, git push вполне себе правильный - non fast forward только по -f. а
как такое же сделать с git pull? я так и не нашел способа запретить ему
merge, оставив только fast-forward.

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

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

Re: [devel] о культуре работы с git-репозиториями (was: [SCM] packages/qemu: heads/master)

[Alexey I. Froloff]

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

On Sun, Jan 10, 2010 at 07:22:05PM +0300, Afanasov Dmitry wrote:
> кстати, git push вполне себе правильный - non fast forward только по -f. а
> как такое же сделать с git pull? я так и не нашел способа запретить ему
> merge, оставив только fast-forward.
git fetch, lol!

-- 
Regards,    --
Sir Raorn.   --- http://thousandsofhate.blogspot.com/

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

Re: [devel] о культуре работы с git-репозиториями (was: [SCM] packages/qemu: heads/master)

[Afanasov Dmitry]

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

On Sun, Jan 10, 2010 at 07:37:13PM +0300, Alexey I. Froloff wrote:
> On Sun, Jan 10, 2010 at 07:22:05PM +0300, Afanasov Dmitry wrote:
> > кстати, git push вполне себе правильный - non fast forward только по -f. а
> > как такое же сделать с git pull? я так и не нашел способа запретить ему
> > merge, оставив только fast-forward.
> git fetch, lol!
да кто бы спорил! так и работаем:

git fetch
ref=``git merge-base master origin/master`
[ "$ref" = "`git rev-parse HEAD`" ] && git merge

хотя этот изврат конечно заменяю на qgit master origin/master :)

кто вспомнит про -ff:
--ff, --no-ff
        Do not generate a merge commit if the merge resolved as
        a fast-forward, only update the branch pointer.

к сожалению тут "if resolved". если not resolved, то просходит обычный
merge, а я его хочу запретить, пока не будет сказано дополнительно.

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

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

Re: [devel] git-merge-base

[Dmitry V. Levin]

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

On Sun, Jan 10, 2010 at 07:54:03PM +0300, Afanasov Dmitry wrote:
> On Sun, Jan 10, 2010 at 07:37:13PM +0300, Alexey I. Froloff wrote:
> > On Sun, Jan 10, 2010 at 07:22:05PM +0300, Afanasov Dmitry wrote:
> > > кстати, git push вполне себе правильный - non fast forward только по -f. а
> > > как такое же сделать с git pull? я так и не нашел способа запретить ему
> > > merge, оставив только fast-forward.
> > git fetch, lol!
> да кто бы спорил! так и работаем:
> 
> git fetch
> ref=``git merge-base master origin/master`
> [ "$ref" = "`git rev-parse HEAD`" ] && git merge

Это ошибка.  Никогда не используйте git-merge-base для проверки
наследования.  На досуге можете построить контрпример, когда наследование
есть, но git-merge-base показывает на другой коммит.  Посказка: общих
предков может быть более одного.


-- 
ldv

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

Re: [devel] git-merge-base

[Afanasov Dmitry]

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

On Sun, Jan 10, 2010 at 08:05:30PM +0300, Dmitry V. Levin wrote:
> On Sun, Jan 10, 2010 at 07:54:03PM +0300, Afanasov Dmitry wrote:
> > ref=``git merge-base master origin/master`
> > [ "$ref" = "`git rev-parse HEAD`" ] && git merge
> 
> Это ошибка.  Никогда не используйте git-merge-base для проверки
> наследования.  На досуге можете построить контрпример, когда наследование
> есть, но git-merge-base показывает на другой коммит.  Посказка: общих
> предков может быть более одного.
пока не соображу, как такое может случится с master и origin/master, но
данный факт учту. спасибо, его я не знал.

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

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

Re: [devel] о культуре работы с git-репозиториями (was: [SCM] packages/qemu: heads/master)

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

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

On Sun, Jan 10, 2010 at 07:22:05PM +0300, Afanasov Dmitry wrote:

>> Какие есть предложения по решению этой проблемы?
AD> быть проще :) а также позволять себе отказываться от истории.

Мне кажется что это порождает проблем куда больше чем решает.

AD> кстати, git push вполне себе правильный - non fast forward только по -f. а
AD> как такое же сделать с git pull? я так и не нашел способа запретить ему
AD> merge, оставив только fast-forward.

pull = fetch + merge

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

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

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

Re: [devel] о культуре работы с git-репозиториями (was: [SCM] packages/qemu: heads/master)

[Sergey Vlasov]

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

On Sun, Jan 10, 2010 at 07:22:05PM +0300, Afanasov Dmitry wrote:
> кстати, git push вполне себе правильный - non fast forward только по -f. а
> как такое же сделать с git pull? я так и не нашел способа запретить ему
> merge, оставив только fast-forward.

В git >= 1.6.6 у команд git merge и git pull есть опция --ff-only;
при желании можно указать её даже в branch.<name>.mergeoptions.

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

Re: [devel] о культуре работы с git-репозиториями (was: [SCM] packages/qemu: heads/master)

[Afanasov Dmitry]

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

On Sun, Jan 10, 2010 at 08:33:27PM +0300, Sergey Vlasov wrote:
> On Sun, Jan 10, 2010 at 07:22:05PM +0300, Afanasov Dmitry wrote:
> > кстати, git push вполне себе правильный - non fast forward только по -f. а
> > как такое же сделать с git pull? я так и не нашел способа запретить ему
> > merge, оставив только fast-forward.
> 
> В git >= 1.6.6 у команд git merge и git pull есть опция --ff-only;
> при желании можно указать её даже в branch.<name>.mergeoptions.
благодарю. значит мне не хочется очередной раз странного :)

пока у нас git-1.6.5.7-alt1. будем иметь в виду.

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

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

Re: [devel] о культуре работы с git-репозиториями (was: [SCM] packages/qemu: heads/master)

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

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

On Sun, Jan 10, 2010 at 08:33:27PM +0300, Sergey Vlasov wrote:

SV> В git >= 1.6.6 у команд git merge и git pull есть опция --ff-only;
SV> при желании можно указать её даже в branch.<name>.mergeoptions.

Ой, спасибо!

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

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

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

Re: [devel] о культуре работы с git-репозиториями

[REAL]

Afanasov Dmitry пишет:
> кроме +1 добавлю -s ours, который проверки на непрерывность истории
> превращает в издевательство; постоянные вычисления к какому
> же бранчу относятся ветки истории и какого ляда его переименовали.

Тут причина может быть только одна, точнее две:

1. Собирали из tar, стали собирать из репозитория апстрима.
2. Собирали из репозитория апстрима, но он (репозиторий) сменился.

Мержи без -s ours в бранч upstream порой приводят к такому жуткому 
бреду, что лучше и не вспоминать. В этой случае, на мой взгляд, 
вариант может быть таким:

1. старый бранч upstream переименовываем, делаем новый по типу git 
checkout -b upstream git-svn
2. старый бранч просто убиваем, толку от лишнего бранча нет.
3. старый бранч master переименовываем (скажем, git branch -m master 
master.old), делаем git checkout -b master upstream
4. git merge master.old --no-commit, сразу складываем старые 
мастер-файлы в нужное место и git commit.
5. [опционально] master.old убить или оставить. Для истории.

Где-то так мне видится ситуация, но её бы отточить, тем, у кого опыта 
больше.

-- 

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

Re: [devel] о культуре работы с git-репозиториями

[REAL]

REAL пишет:
> 4. git merge master.old --no-commit, сразу складываем старые 
> мастер-файлы в нужное место и git commit.

Тут тоже -s ours не хватает.

PS. Вообще, жуткая эта вещь - перевод сборки в gear с tar на 
апстримный репозиторий. История в пакете явно будет очень некрасивой.

-- 

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

Re: [devel] о культуре работы с git-репозиториями

[Afanasov Dmitry]

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

On Tue, Jan 12, 2010 at 07:11:08PM +0700, REAL wrote:
> REAL пишет:
> > 4. git merge master.old --no-commit, сразу складываем старые 
> > мастер-файлы в нужное место и git commit.
> 
> Тут тоже -s ours не хватает.
> 
> PS. Вообще, жуткая эта вещь - перевод сборки в gear с tar на 
> апстримный репозиторий. История в пакете явно будет очень некрасивой.
я не использую историю апстрима в git. очень уж она зашумливает
репозитарий, почти как solo@ :)

единственный случай, когда мне приходится делать -s ours - прохождение
проверки girar-builder'а на непрерывность истории.
-- 
С уважением
Афанасов Дмитрий

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

Re: [devel] о культуре работы с git-репозиториями

[Dmitry V. Levin]

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

On Sun, Jan 10, 2010 at 01:32:54PM +0200, Michael Shigorin wrote:
> On Sun, Jan 10, 2010 at 04:08:13AM +0300, Dmitry V. Levin wrote:
> > Историю коммитов невозможно пропатчить.
> 
> Возможно, но работать с таким репозиторием другим крайне неудобно.

Это ещё мягко сказано.

> > > PS: Я не настаиваю именно на своём варианте:
> > Однако вы настаиваете на своём методе, который по сути есть ни
> > что иное как графо^Wгитоманство и перевод чернил^Wкоммитов.
> > Грустно смотреть, на что порой расходуют себя умные люди.
> 
> Дим, если ты (наивно) полагал, что на gear-srpmimport поиск
> вариантов и преподавание хороших примеров закончится -- это
> не так.

Я полагал, что с gear-srpmimport всё только начнётся.  Самые
распространённые и удобные (для соответствующих задач) были несколько
лет назад записаны в gear-rules(5).  На wiki наверняка ещё что-то
зафиксировано.  Полезные открытия можно и в gear-rules(5) добавить,
полагаю что никто возражать против этого не станет.

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

В дружной семье без сам-знаешь-кого не обходится.

> Меня вот тошнит от мегапатча или вообще бухнутого в тарбол
> master, в котором леший ногу сломит

Эти файлы предназначены для только hasher и ни для чего другого, кроме
hasher.  Если тебе они не нравятся, это значит, что ты не hasher. :)

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

Если ты используешь srpm для общения с апстримом и коллегами-мейнтейнерами --
значит, ты живёшь в прошлом веке.  Пора модернизироваться.  Апстримы, как
правило, любят патчи в формате git-format-patch, а не ссылки на srpm'ы.
И коллеги-мейнтейнеры любят ссылки не на srpm'ы, а на репозитории с
историей.


-- 
ldv

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

Re: [devel] о культуре работы с git-репозиториями

[Michael Shigorin]

On Sun, Jan 10, 2010 at 08:36:19PM +0300, Dmitry V. Levin wrote:
> > > Грустно смотреть, на что порой расходуют себя умные люди.
> > Дим, если ты (наивно) полагал, что на gear-srpmimport поиск
> > вариантов и преподавание хороших примеров закончится -- это
> > не так.
> Я полагал, что с gear-srpmimport всё только начнётся.

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

Иначе новички ещё ничего, а вот матёрый контингент такое может
учинить, что не расхлебаешь.

> Самые распространённые и удобные (для соответствующих задач)
> были несколько лет назад записаны в gear-rules(5).  На wiki
> наверняка ещё что-то зафиксировано.  Полезные открытия можно и
> в gear-rules(5) добавить, полагаю что никто возражать против
> этого не станет.

Ещё бы.  Кстати, тут упоминали, что в гите сейчас более
расписанная именно по вариантам страничка gear-rules(5) --
возможно ли втащить в пакет, чтоб можно было почитать локально,
не выискивая по гитам?

> > Хотел гит?  Получи гит.  Предупреждали о том, что
> > использовать его можно сильно по-разному?  Пропустил
> > мимо ушей, теперь "кушайте, не обляпайтесь".
> В дружной семье без сам-знаешь-кого не обходится.

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

> > Меня вот тошнит от мегапатча или вообще бухнутого в тарбол
> > master, в котором леший ногу сломит
> Эти файлы предназначены для только hasher и ни для чего
> другого, кроме hasher.  Если тебе они не нравятся, это значит,
> что ты не hasher. :)

Тогда стоит как минимум оторвать поддержку публикации патчей
на sisyphus.ru и prometheus.altlinux.org.  Хотя многие лазят
по SRPMS, сам не исключение (применительно к тем же Fedora,
openSUSE, Mandriva, PLD).

> > -- у тебя таких гитов довольно много, а между тем srpm с
> > разложенными патчами куда дружественней и уважительней по
> > отношению к другим, чем такое.
> Если ты используешь srpm для общения с апстримом и
> коллегами-мейнтейнерами -- значит, ты живёшь в прошлом веке.
> Пора модернизироваться.  Апстримы, как правило, любят патчи в
> формате git-format-patch, а не ссылки на srpm'ы.

Мои принимают и просто патчи.

> И коллеги-мейнтейнеры любят ссылки не на srpm'ы, а на
> репозитории с историей.

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

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

Re: [devel] о культуре работы с git-репозиториями

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

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

On Sun, Jan 10, 2010 at 08:00:25PM +0200, Michael Shigorin wrote:

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

Тут проблема в том, что никто не знает как идеально. Увы, чтобы найти
оптимальные формы для репо -- таки надо было сначала внедрить :(

MS> Тогда стоит как минимум оторвать поддержку публикации патчей
MS> на sisyphus.ru и prometheus.altlinux.org.  Хотя многие лазят
MS> по SRPMS, сам не исключение (применительно к тем же Fedora,
MS> openSUSE, Mandriva, PLD).

Разумно.

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

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

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

Re: [devel] о культуре работы с git-репозиториями

[Michael Shigorin]

On Mon, Jan 11, 2010 at 12:04:10AM +0300, Денис Смирнов wrote:
> MS> Дело в том, что удостовериться в найденности, документированности
> MS> и доступности иных типичных путей штатным для существующих и
> MS> новых майнтейнеров образом стоило _перед_ тем, как вводить сборку
> MS> в промышленную эксплуатацию и тем более загонять на неё новичков
> MS> безальтернативно.
> Тут проблема в том, что никто не знает как идеально. Увы, чтобы
> найти оптимальные формы для репо -- таки надо было сначала
> внедрить :(

Мой опыт внедренца говорит, что пилотный проект в подобных
случаях совершенно необходим.  Причём не ради галочки, а с
ловлей и исправлением проблем _до_ их тиражирования.

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

Re: [devel] о культуре работы с git-репозиториями

[Dmitry V. Levin]

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

On Sun, Jan 10, 2010 at 08:00:25PM +0200, Michael Shigorin wrote:
[...]
> Тогда стоит как минимум оторвать поддержку публикации патчей
> на sisyphus.ru и prometheus.altlinux.org.  Хотя многие лазят
> по SRPMS, сам не исключение (применительно к тем же Fedora,
> openSUSE, Mandriva, PLD).

Раньше смотрели, наверное.  Сейчас вряд ли.  У Fedora есть
cvs.fedoraproject.org, у Mandriva -- svn.mandriva.com, у PLD --
cvs.pld-linux.org, и смотреть там существенно удобнее, чем раньше
было в SRPMS.


-- 
ldv

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

Re: [devel] о культуре работы с git-репозиториями

[Michael Shigorin]

On Mon, Jan 11, 2010 at 12:27:03AM +0300, Dmitry V. Levin wrote:
> Раньше смотрели, наверное.  Сейчас вряд ли.  У Fedora есть
> cvs.fedoraproject.org, у Mandriva -- svn.mandriva.com, у PLD --
> cvs.pld-linux.org, и смотреть там существенно удобнее, чем
> раньше было в SRPMS.

И там типично есть отдельные патчи, а не мегаужас.
(как если бы в cvs/svn были _толком_ бранчи...)

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

Re: [devel] о культуре работы с git-репозиториями

[Anton Farygin]

11.01.2010 00:27, Dmitry V. Levin пишет:
> On Sun, Jan 10, 2010 at 08:00:25PM +0200, Michael Shigorin wrote:
> [...]
>> Тогда стоит как минимум оторвать поддержку публикации патчей
>> на sisyphus.ru и prometheus.altlinux.org.  Хотя многие лазят
>> по SRPMS, сам не исключение (применительно к тем же Fedora,
>> openSUSE, Mandriva, PLD).
>
> Раньше смотрели, наверное.  Сейчас вряд ли.  У Fedora есть
> cvs.fedoraproject.org, у Mandriva -- svn.mandriva.com, у PLD --
> cvs.pld-linux.org, и смотреть там существенно удобнее, чем раньше
> было в SRPMS.

согласен. У меня в history уже давно болтаются команды, позволяющие 
забрать cvs из fedora или mandriva.

Но они хранят в cvs не код upstream, а свои патчи и спеки. 
Соответственно их репозитории значительно меньше по объёму, проще 
забираются и анализируются со стороны, что нельзя сказать о нас.

Re: [devel] [SCM] packages/qemu: heads/master

[Aleksey Avdeev]

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

10.01.2010 04:08, Dmitry V. Levin пишет:
> On Thu, Dec 31, 2009 at 01:39:34AM +0300, Aleksey Avdeev wrote:
>> 31.12.2009 01:05, Dmitry V. Levin пишет:
>>> On Thu, Dec 31, 2009 at 12:15:21AM +0300, Aleksey Avdeev wrote:
>>>> 31.12.2009 00:06, Dmitry V. Levin пишет:
>>>>> Aleksey, PLEASE STOP poisoning repositories!
>>>>
>>>> ?
>>>
>>> Пожалуйста, хватит отравлять нормальные репозитории, вмерживая туда
>>> засоряющие их коммиты!  Несколько десятков коммитов для того, чтобы
>>> внести тривиальное изменение в спек!!  Неужели не очевидно, что это
>>> ужасно???
>>
>>   Не очевидно, т. к. данный минус перекрывается плюсами:
>>
>> 1. _Сразу_ видно откуда растут данные изменения: сохраняется история
>> каждой вмерженной фичи.
> 
> В данном случае у изменения в несколько строк история в 42 коммита:
> 
> $ git diff --stat 0.11.92-alt1..0.11.92-alt1-42-g44d98bd
>  qemu.spec |    8 +++++---
>  1 files changed, 5 insertions(+), 3 deletions(-)

  Да. И 3 строчки данных изменений опираются на вмерженные изменения
репозитория specs.git (см.
<http://git.altlinux.org/people/solo/public/specs.git?p=specs.git;a=commitdiff;h=ac8bb6364cd7432255b61a64d147c1691635ea7f>):

$ git diff --stat ac8bb6364cd7432255b61a64d147c1691635ea7f{^,}
 sample.spec |   22 ++--------------------
 1 files changed, 2 insertions(+), 20 deletions(-)

  И изменятся ли эти 3, привнесённые из specs.git, строчки далее -- я
предсказать не берусь.

> 
> И чтение вывода git log 0.11.92-alt1..0.11.92-alt1-42-g44d98bd не наводит
> (меня, по крайней мере) не на какие конструктивные мысли.

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

commit b936e08ac4383f23fc068a96cebf94bcb3921df5
Merge: 62d4d54 69e4cf6
Author: Aleksey Avdeev <solo@altlinux.ru>
Date:   Sun Dec 27 03:41:30 2009 +0300

    Merge branch 'ALT/release/distr/program' of
git://git.altlinux.org/people/solo/public/specs into ALT/qemu/sample/spec

> 
>> 2. Устаревшая реализация фичи легко меняется на свежую, с помощью мержа.
>> И как показала практика обновления автоматизатированной генерации
>> релизов (переход от кучи макросов к %branch_release) -- достаточно
>> простого мержа.
> 
> Легко меняется?  Там всего несколько строк изменений, однако _каждый_ merge
> приводит к конфликту, который приходится исправлять вручную.

  О каких именно мержах идёт речь?

  У меня есть репозитории где переход от автовычеслялки старого типа к
использованию %branch_release (приведённый выше diff) выполнялся с
помощью мержа с бранчем содержащим коммит
ac8bb6364cd7432255b61a64d147c1691635ea7f. Конфликт был простейшим (релиз
был не alt1).

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

  Готов её переписать, если требуется. (Или исправить без переписывания,
дабы не тиражировать ошибки далее.)

> 
>> PS: Я не настаиваю именно на своём варианте:
> 
> Однако вы настаиваете на своём методе, который по сути есть ни что иное
> как графо^Wгитоманство и перевод чернил^Wкоммитов.  Грустно смотреть, на
> что порой расходуют себя умные люди.

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

  Предложение приветствуются.

-- 

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



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

Re: [devel] [SCM] packages/qemu: heads/master

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

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

On Thu, Dec 31, 2009 at 01:05:00AM +0300, Dmitry V. Levin wrote:

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

Совершенно бесплатно (дажене по 50$/час!) учу членов тим читать man на
предмет:

git cherr-pick на предмет -n
git rebase
git amend

а также применять полученные знания на практике.

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

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

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

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

Re: [devel] [SCM] packages/qemu: heads/master

[Michael Shigorin]

On Thu, Dec 31, 2009 at 01:42:56AM +0300, Денис Смирнов wrote:
> git cherr-pick на предмет -n

Спасибо, не знал.

> Переписывание истории -- один из очень ценных инструментов в
> git, позволяющий публиковать красивые репозитории а не
> нечитаемый кошмар :)

Напомню также: http://tomayko.com/writings/the-thing-about-git
(git add --patch, git rebase --interactive, git stash)

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

Re: [devel] [SCM] packages/qemu: heads/master

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

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

On Thu, Dec 31, 2009 at 01:01:50PM +0200, Michael Shigorin wrote:

>> git cherr-pick на предмет -n
MS> Спасибо, не знал.

(скромно) мне тоже в devel@ посоветовали :)

>> Переписывание истории -- один из очень ценных инструментов в
>> git, позволяющий публиковать красивые репозитории а не
>> нечитаемый кошмар :)
MS> Напомню также: http://tomayko.com/writings/the-thing-about-git
MS> (git add --patch, git rebase --interactive, git stash)

Вот к этим волшебным приемам пока не привык :(

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

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

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