[devel] collaboration patterns (was: FAILED fpc.git=2.2.4-alt1)

[devel] collaboration patterns (was: FAILED fpc.git=2.2.4-alt1)

[Alexey Tourbin]

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

On Fri, Apr 24, 2009 at 08:01:39PM +0300, Slava Dubrovskiy wrote:
> >>> Why?  Just rebuild that another package with new fpc.
> >>>       
> >> Чтобы этот другой пакет пересобрать с новым fpc, нужно чтобы он (новый
> >> fpc) попал в репозитарий. А он не может, т.к. анметы не пускают.
> >> Замкнутый круг.
> >> Я так понимаю нужно или собирать все одновременно, или делать две версии
> >> fpc.
> >>     
> > Yes, you have to add that another package to your fpc task.
> > If you have ACL permissions to build that another package,
> > this is remarkably simple. :)  And if you don't, this is still
> > possible.
> >   
> Да, наверно сейчас, когда такой пакет всего один, это будет просто. А
> если завтра их будет больше одного? А каждый мантейнер личность и к
> каждому найти подход...

Okay, let's discuss again what I call "collaboration patterns".  The
problem is that we need to find the right balance between two things:
1) the maintainer must be responsible for the package, and thus she should
be able to control other the package; 2) sometimes, when it comes to the
repo, there should be other ways to make minor changes to the package,
perhaps even without the maintainer.

I see the following possibilities:

1) For fpc packages and packages which have fpc parts, you may ask
for permanent ACL permissions as a co-maintainer.  There might be
an informal agreement between you and maintainer so that you can
make fpc-related changes without prior notice (and otherwise discuss
any changes first).

2a) You can ask her for single NMU ACK.

2b) You can ask girar administrator for single NMU ACK.

3) You can share your fpc task and ask her to push new package
into your shared fpc task.

Are there any better possibilities?  I believe we need to make
rebuilding packages for new dependencies easily possible.  And
otherwise we face major problems.

> > Please don't do the second fpc package.
> Конечно не буду.

Now, what is the problem with two fpc packages, e.g. fpc1 and fpc2?
Consider there are two external fpc modules, foo-fpc and bar-fpc.
It is then possible that foo-fpc was build with fpc1, while bar-fpc
was built with fpc2.  So what?  There are no unmet dependencies,
but you cannot use both fpc-foo and fpc-bar for in a single program.

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

Re: [devel] collaboration patterns (was: FAILED fpc.git=2.2.4-alt1)

[Afanasov Dmitry]

2009/4/24, Alexey Tourbin <at@altlinux.ru>:
> On Fri, Apr 24, 2009 at 08:01:39PM +0300, Slava Dubrovskiy wrote:
>  > Да, наверно сейчас, когда такой пакет всего один, это будет просто. А
>  > если завтра их будет больше одного? А каждый мантейнер личность и к
>  > каждому найти подход...
>  I see the following possibilities:
>  1) you may ask for permanent ACL permissions as a co-maintainer.
>  2a) You can ask her for single NMU ACK.
>  2b) You can ask girar administrator for single NMU ACK.
>  3) You can share your fpc task
>
>  Are there any better possibilities?
мне всё C на ум просится - versioning не сюда относится?

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

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

но я  конечно могу ошибаться :)

>  There are no unmet dependencies,
>  but you cannot use both fpc-foo and fpc-bar for in a single program.
согласен, придется расщеплять и %_libdir/fpc/units/i386-linux/, что
неудобно, и версионировать и юниты.

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

Re: [devel] collaboration patterns (was: FAILED fpc.git=2.2.4-alt1)

[Alexey Tourbin]

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

On Fri, Apr 24, 2009 at 09:57:02PM +0400, Afanasov Dmitry wrote:
> 2009/4/24, Alexey Tourbin <at@altlinux.ru>:
> > On Fri, Apr 24, 2009 at 08:01:39PM +0300, Slava Dubrovskiy wrote:
> >  > Да, наверно сейчас, когда такой пакет всего один, это будет просто. А
> >  > если завтра их будет больше одного? А каждый мантейнер личность и к
> >  > каждому найти подход...
> >  I see the following possibilities:
> >  1) you may ask for permanent ACL permissions as a co-maintainer.
> >  2a) You can ask her for single NMU ACK.
> >  2b) You can ask girar administrator for single NMU ACK.
> >  3) You can share your fpc task
> >
> >  Are there any better possibilities?
> мне всё C на ум просится - versioning не сюда относится?
> 
> и вторая мысль - что случится, если у модуля добавилась функция, а
> остальное осталось прежним? crc будет новым, а вот символы в модуле
> сохранятся.
> 
> черт, надо разобраться, как работает fpc. как я понял, он вызывает ld
> для линковки статики и динамики, а значит должен поддерживать работу и
> с новыми модулями с имзененным crc.
> 
> но я  конечно могу ошибаться :)

RTFS.

fpcbuild-2.2.0/fpcsrc/compiler/fppu.pas:
  1204          { load the used units from interface }
  1205          in_interface:=true;
  1206          pu:=tused_unit(used_units.first);
  1207          while assigned(pu) do
  1208           begin
  1209             if pu.in_interface then
  1210              begin
  1211                tppumodule(pu.u).loadppu;
  1212                { if this unit is compiled we can stop }
  1213                if state=ms_compiled then
  1214                 exit;
  1215                { add this unit to the dependencies }
  1216                pu.u.adddependency(self);
  1217                { need to recompile the current unit, check the interface
  1218                  crc. And when not compiled with -Ur then check the complete
  1219                  crc }
  1220                if (pu.u.interface_crc<>pu.interface_checksum) or
  1221                   (
  1222                    ((ppufile.header.flags and uf_release)=0) and
  1223                    (pu.u.crc<>pu.checksum)
  1224                   ) then
  1225                 begin
  1226                   Message2(unit_u_recompile_crc_change,realmodulename^,pu.u.realmodulename^,@queuecomment);
  1227                   recompile_reason:=rr_crcchanged;
  1228                   do_compile:=true;
  1229                   exit;
  1230                 end;
  1231              end;
  1232             pu:=tused_unit(pu.next);
  1233           end;

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

Re: [devel] collaboration patterns (was: FAILED fpc.git=2.2.4-alt1)

[Afanasov Dmitry]

2009/4/24, Alexey Tourbin <at@altlinux.ru>:
> On Fri, Apr 24, 2009 at 09:57:02PM +0400, Afanasov Dmitry wrote:
>  > как я понял, он вызывает ld
>  > но я  конечно могу ошибаться :)
>   1220                if (pu.u.interface_crc<>pu.interface_checksum) or
я действительно ошибался. значит работает по перечисленным
collaboration паттернам.

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

Re: [devel] collaboration patterns (was: FAILED fpc.git=2.2.4-alt1)

[Damir Shayhutdinov]

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

Re: [devel] collaboration patterns (was: FAILED fpc.git=2.2.4-alt1)

[Alexey Tourbin]

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

On Fri, Apr 24, 2009 at 10:48:23PM +0400, Damir Shayhutdinov wrote:
> >> Да, наверно сейчас, когда такой пакет всего один, это будет просто. А
> >> если завтра их будет больше одного? А каждый мантейнер личность и к
> >> каждому найти подход...
> Создайте команду fpc@

$ l libnumerix-*
-rw-r--r-- 2 copy copy  73278 Aug 25  2008 libnumerix-0.22-alt1.x86_64.rpm
-rw-r--r-- 2 copy copy   7630 Aug 25  2008 libnumerix-devel-0.22-alt1.x86_64.rpm
-rw-r--r-- 2 copy copy  14001 Aug 25  2008 libnumerix-fpc-unit-0.22-alt1.x86_64.rpm
-rw-r--r-- 2 copy copy 261088 Aug 25  2008 libnumerix-ocaml-0.22-alt1.x86_64.rpm
$

So, there is both -fpc and -ocaml parts.

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

Re: [devel] collaboration patterns (was: FAILED fpc.git=2.2.4-alt1)

[Alexey Tourbin]

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

On Fri, Apr 24, 2009 at 09:43:58PM +0400, Alexey Tourbin wrote:
> 3) You can share your fpc task and ask her to push new package
> into your shared fpc task.

BTW, you don't need another task for this.
You can share the existing task that failed.

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

Re: [devel] collaboration patterns (was: FAILED fpc.git=2.2.4-alt1)

[Slava Dubrovskiy]

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

On 24.04.2009 22:13, Alexey Tourbin wrote:
> On Fri, Apr 24, 2009 at 09:43:58PM +0400, Alexey Tourbin wrote:
>   
>> 3) You can share your fpc task and ask her to push new package
>> into your shared fpc task.
>>     
> BTW, you don't need another task for this.
> You can share the existing task that failed.
>   
Не знал. Буду знать.
Спасибо.

-- 
WBR,
Dubrovskiy Vyacheslav


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3262 bytes --]

[devel] sisyphus-unmets: "смягчить" работу над shared tasks (was: collaboration patterns)

[Michael Shigorin]

On Fri, Apr 24, 2009 at 09:43:58PM +0400, Alexey Tourbin wrote:
> > > Yes, you have to add that another package to your fpc task.
> > > If you have ACL permissions to build that another package,
> > > this is remarkably simple. :)  And if you don't, this is
> > > still possible.
> > Да, наверно сейчас, когда такой пакет всего один, это будет
> > просто. А если завтра их будет больше одного? А каждый
> > мантейнер личность и к каждому найти подход...
> Okay, let's discuss again what I call "collaboration patterns".
[...]
> Are there any better possibilities?  I believe we need to make
> rebuilding packages for new dependencies easily possible.  And
> otherwise we face major problems.

Yup.

Вот что ещё подумалось: а можно ли обломавшиеся по причине
создания новых анметов задания сваливать в некую общую кучу
sisyphus-unmets или там sisyphus-next, в рамках которой не
требовалось бы отдельных действий по координации для исправления?

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

Возможность реализации IMHO зависит от того, насколько получается
предположить возможность исправления целостности получаемого
репозитория новоприбывшими пакетами -- примерно так:

- залил новые A и B;
- A собрался/проверился нормально и пошёл в Sisyphus;
- B сломал по установочным зависимостям пакеты C и D
  и потому был отправлен в sisyphus-unmets;
- майнтейнер C забросил новую сборку в git.alt или incoming;
- её пересборка в окружении sisyphus-unmets показала
  уменьшение количества анметов при транзакции
  => пакет определён в sisyphus-unmets;
- майнтейнер D тоже забросил сборку, но она не уменьшила
  количества анметов в рамках sisyphus-unmets, при этом
  пересборка на sisyphus показала неувеличение анметов
  => пакет определён в sisyphus;
- когда все порождённые B анметы "погашены" определёнными
  в sisyphus-unmets пакетами, B и пакеты, скомпенсировавшие
  именно им созданные анметами, отправляются на пересборку
  в Sisyphus (и при прохождении перекладываются туда).

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

А ещё судьба пакета C может быть неожиданной для майнтейнера,
который и не собирался как-то особенно исправлять судьбу пакета B
(даже быть не в курсе), а просто намеревался увидеть новую сборку
пакета C в сизифе.

---

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

Получилось же сделать task add srpm, за что отдельное спасибо.

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