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

[Alexey Tourbin <at@altlinux.ru>]

[-- 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 --]