Re: [devel] I: nut-2.2.2

[Aleksey Avdeev <solo@solin.spb.ru>]

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

Dmitry V. Levin пишет:
> On Tue, Feb 10, 2009 at 05:58:40PM +0300, Aleksey Avdeev wrote:
>> Dmitry V. Levin пишет:
>> ...
>>> Очень сложно и очень неудобно.  Нет, это 
>>> ужасно.
>>   Есть более удобный вариант?
> 
> Просто поменять имя релиза и выполнить add_changelog существенно проще.

1. Имя релиза в бранче у нас жёстко связано с релизом в сизифе, и может 
быть вычислено автоматически. Так, зачем его вводить вручную, рискуя 
нарваться на очепятку (которую можно и вообще не заметить)?

2. В %changelog нужно ещё добавить комментарий. Хотя бы стандартный 
Backports to <>.

   Да, оба эти пункта способна реализовать утилита...

> Я слышал, что есть утилита, которая делает это ещё проще.

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

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

а) разнести бэкпорты по разным бранчам;

б) убрать ветвления в спеках.

   Но тогда потеряем возможность варьировать сборку в отрыве от 
репозитария. Сейчас у меня это возможно: для любого srpm (независимо от 
бранча под который он был собран) целевой дистрибутив можно задать через 
параметры командной строки rpmbuild`а: пакет соберётся с под заданный 
бранч с нужным релизом (да, приэтом он может отличаться от того что уже 
есть в changelog`е).

> 
> Разводить на каждое изменение в spec-файле по бранчу -- извините, это
> злоупотребление git'ом.

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

2. Хорошо страхует от потери изменений.

   Да, количество бранчей можно сократить, сделав упор на cherry-pick и 
rebase. Но тогда будет страдать поддерживаемость кода...

PS: Да, код получился довольно объёмным. И я пока не придумал, как его 
разместить по внешним макросам.

-- 

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



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