[cl-debian] Moving to darcs.debian.org, co-maintenance and other bits

[Luca Capello]

Hello!

I'm sorry, another long post :-)

On Mon, 08 Oct 2007 05:02:08 +0200, Pierre THIERRY wrote:
> Scribit Luca Capello dies 08/10/2007 hora 02:27:
>> obviously, having only one VCS would be easier to learn and
>> maintain, but whenever it's possible I prefer to follow upstream,
>> providing that they use a distributed VCS.
>
> In my case, it's not to follow upstream that I use Mercurial (most
> of my upstreams don't have any VCS...), it's merely because it's the
> VCS I know very well by using it for my everyday work.

As I said, at the end it's a matter of taste.  The message I wanted to
pass was that I don't see the point in having one VCS to rule the
others, since most of the time the basic commands are quite simple.

>> This doesn't mean that the packages will be automagically and
>> suddenly co-maintained by all of us, but that there's still a
>> principal maintainer, while the others can sparely act on the
>> package in case of urgency or small fixes.
>
> While I wouldn't really see an issue in having all repositories
> writable by the whole group, I'd just note that it's not all that
> needed if we mostly use DCVSes.

Read below below ;-)

> In any case, I suppose that it would be good to have a minimal set
> of rules about where commits go. I would prefer that each package
> (or group of packages when they share a repo...) have some main repo
> where there is only history of code actually going into Debian.

Fully ACK.

> That is, modifications committed for the maintainers of the package
> to review would go in a separate repo, whereas an urgent fix for
> which there is a package uploaded by a DD should go in that main
> repo.

And this main repository needs to be writable by at least the DDs that
upload it.  The general idea behind co-maintenance is not package
hijacking, but mostly overcome those situations when the maintainer is
busy, on holidays or, even worse, not responsive.

> Clear (read: written) rules about who can upload would also probably
> be good (i.e. that everyone can write in the repos won't necessarily
> mean every DD should upload the package...)

This is another point: we should distinguish between DDs involved in
the CL-Debian project and any DDs outside it.  While the former should
be able to upload any package from the project [1][2], the
latter should be avoided if the modifications touch the package code.

> Not that I would mind that anyone upload any of my packages at the
> moment. ;-)

I read your post, but while I'm indeed a DD since Aug 4th, I still
cannot upload, because only my old and lost GPG key has been included
in the Debian keyring (see the thread at [3]).  So, I'm waiting for
the new GPG key to be included in the Debian keyring as well.

>> I think that implementing a partial co-maintenance will be anyway
>> worth it,
>
> I suppose each package under co-maintainance would be a gain, even
> for a small fraction of the CL packages in Debian.

Fully ACK.

>> A further step in co-maintenance would be to allow write permission
>> to DDs outside the CL-Debian project
>
> Inbox repos could be a good thing here, I'd say.
>
>> This could be really useful for translators, for example.
>
> And targetted inbox repos here.

Are you proposing something like the following?

  $PACKAGE
    =>  repository that gives origin to the Debian package

  $PACKAGE.upstream
    =>  upstream repository (this is probably specific to darcs, but
        it's just to give an idea)

  $PACKAGE.contrib
    =>  repository for people outside the CL-Debian project, where
        patches can be submitted for peer-review

If most of our repositories use DVCSs, however, I don't see how the
latter would be so different from a patch in the BTS (which is where
I'd like to receive all the patches or notifications, even if other
people can commit).

>> 5) Whatever we decide about a full or partial co-maintenance
>
> As it is a matter of control, I'd suggest to be conservative and
> make that an opt-in. If everyone wants to do it, that's great, but
> if that's not the case, we avoid any possible conflict.

Exactly, this is why after having discussed with Peter and René I
wrote this mail instead of directly acting :-)

>> we should decide if we want to keep the current project name
>
> I'd vote for debian-lisp or pkg-cl (a short name might prove
> handy...).

pkg-cl-* is my preferred, too, since this syntax is the most used in
Debian.  However, grepping my /var/lib/dpkg/status for
lists.alioth.debian.org gives different results (I think I've reported
one example for all of them):

    Debian GNOME Maintainers <pkg-gnome-maintainers at ...>
    Debian GnuTLS Maintainers <pkg-gnutls-maint at ...>
    Debian Fonts Task Force <pkg-fonts-devel at ...>

    Debian XML/SGML Group <debian-xml-sgml-pkgs at ...>

    Dpatch Maintainers <dpatch-maintainers at ...>

    Debconf Developers <debconf-devel at ...>

    CDBS Hackers <build-common-hackers at ...>

If we include clc in the CL-Debian project, we not only maintain
Debian packages, but we develop software, too.  Thus, I'd say the best
name would be

    Debian Common Lisp Team <pkg-cl-devel at ...>

with the variants Force/Group.  This because I don't see the need for
two different -maintainers and -devel lists, also considering that the
actual list is low traffic.

>> Always WRT the mailing list, we can also ask for a commit mailing
>> list, where all the commit to the different package archives will
>> be automatically posted.  Would it be useful?
>
> Depends on the traffic, I suppose. Let's try!

I guess the mailing list (pkg-cl-commits) should be read-only
(i.e. only commits can be automatically posted) and without archives,
since I don't see the need of a commit archive when you've the VCS
changelog anyway.

>> I found that clc (the Common Lisp Controller) has its own Alioth
>> project
>
> It doesn't seem to be really used: no BTS, no tasks, no lists. So
> I'd say we host clc in the pkg-cl project.

Fully ACK.  Kevin, Peter, what do you think about it?

Thx, bye,
Gismo / Luca

Footnotes: 
[1] obviously, after having checked that the package reaches the
    Debian standards
[2] this won't be so different from sponsorhip and following Don's
    recommendations explained at
      http://lists.debian.org/debian-devel/2007/08/msg00531.html      
[3] http://albatross.madduck.net/pipermail/debian-unizh/2007-February/000842.html