[cl-debian] Moving to darcs.debian.org, co-maintenance and other bits
Hi all, I directly mailed all the people that I'm aware are involved in Common Lisp packaging for Debian to be sure they read this mail (which is quite long). Don't take this mail as personal: this is just an attempt to improve the current CL-Debian project. 1) Since Oct 4th, Alioth supports also darcs as VCS [1]. This means that we can move all the darcs maintained packages [2] to the commond darcs infrastructure, which is managed as explained at [3]: http://darcs.debian.org/$GROUP/$PACKAGE I'll start to move my packages as soon as the others keypoint expressed below are cleared. 2) AFAIK, at least three different VCSs are used for CL-Debian stuffs: bzr, darcs and git (this one especially by Kevin). Moreover, Pierre has prepared his packages using mercurial [4]. For this reason, I think that we should ask for a $GROUP folder in all of the VCSs we use, similar to the collab-maint project [5]. In this regard, I don't think we should restrict the number of VCSs we use: 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. For example, all of my packages are in darcs: the upstream BESE ones [6] are in darcs, too, while the others upstream are in CVS. However, since StumpWM recently moved to git [7], I'm planning to follow that move for the Debian package as well, leaving darcs in favor of git. 3) During a private discussion between Peter and me, one idea that came out was to go for co-maintenance of the CL-Debian packages. Thus, all the people involved in the project (and registered in the Alioth group) would have write permission to all repositories within the group. 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. To achieve this goal, the Maintainer: field in debian/control will contain the mailing list address (see point 5 below), while the principal maintainer (with all the others involved) will end up in the Uploaders: field. In case someone would argue against this action and would preserve full control over his packages, I think that implementing a partial co-maintenance will be anyway worth it, so point 5 below stands in any case. 4) A further step in co-maintenance would be to allow write permission to DDs outside the CL-Debian project, in a way similar to the collab-maint one, as Stefano explained at [8]. This could be really useful for translators, for example. 5) Whatever we decide about a full or partial co-maintenance and since we're moving to 100% Alioth, we should move the mailing list as well. Doing so, we should decide if we want to keep the current project name or change it to something similar to other packaging groups. The latter includes pkg-commonlisp (or pkg-cl or what else) or simply Common Lisp team (thus common-lisp as the project name). 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? 6) While searching for all the people/groups involved in Common Lisp and Debian, I found that clc (the Common Lisp Controller) has its own Alioth project [9]. Should it be incorporated into the CL-Debian group instead? I hope to have missed nothing and I'm waiting for comments and suggestions. Thx, bye, Gismo / Luca Footnotes: [1] http://lists.debian.org/debian-devel-announce/2007/10/msg00002.html [2] http://cl-debian.alioth.debian.org/repositories/ [3] http://wiki.debian.org/Alioth/darcs [4] http://common-lisp.net/pipermail/cl-debian/2007-September/002836.html [5] http://alioth.debian.org/projects/collab-maint/ [6] http://common-lisp.net/project/bese/ [7] http://lists.gnu.org/archive/html/stumpwm-devel/2007-09/msg00003.html [8] http://www.bononia.it/~zack/blog//posts/2007/08/DD_wide_commit_on_alioth.htm... [9] http://alioth.debian.org/projects/clc/
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.
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. 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. 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. 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...) Not that I would mind that anyone upload any of my packages at the moment. ;-)
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.
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.
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.
we should move the mailing list as well
+1
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...).
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 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. Gladly, Pierre -- nowhere.man@levallois.eu.org OpenPGP 0xD9D50D8A
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@...> Debian GnuTLS Maintainers <pkg-gnutls-maint@...> Debian Fonts Task Force <pkg-fonts-devel@...> Debian XML/SGML Group <debian-xml-sgml-pkgs@...> Dpatch Maintainers <dpatch-maintainers@...> Debconf Developers <debconf-devel@...> CDBS Hackers <build-common-hackers@...> 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@...> 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.htm...
Scribit Luca Capello dies 09/10/2007 hora 21:58:
This is another point: we should distinguish between DDs involved in the CL-Debian project and any DDs outside it.
I would suggest the following repos, by default, for each package. Note that anything but the main repo is optional, and could be created on demand. - debian code actually uploaded by maintainers - upstream upstream code - nmu code uploaded by non-maintainers - proposed code not uplaoded, for review At least git and hg have the ability to hardlink repository data. A Mercurial repo can also be updated to its null revision so as not to have a working copy (or, actaully, an empty one). So we could create automatically a dozen of repos for each package basically at no cost (things like nmu-l10n). We may also have repos or tags to make it easy to track Debian releases. It may not be equally easy for each DVCS. I read that Git makes it hard to have moving tags, for example (and actually discourages it). An upstream repo would only be needed if we don't use upstream's DVCS, actually.
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@...>
+1
I guess the mailing list (pkg-cl-commits) should be read-only [...] and without archives
Yes, the only use is to be notified. Quickly, Pierre -- nowhere.man@levallois.eu.org OpenPGP 0xD9D50D8A
Hi Pierre! On Thu, 11 Oct 2007 00:19:55 +0200, Pierre THIERRY wrote:
Scribit Luca Capello dies 09/10/2007 hora 21:58:
This is another point: we should distinguish between DDs involved in the CL-Debian project and any DDs outside it.
I would suggest the following repos, by default, for each package. Note that anything but the main repo is optional, and could be created on demand.
Fully agree, assuming that "main" means "the one from where the Debian package is built (and uploaded). However...
- upstream upstream code
This is needed for example if you work with darcs-buildpackage (and it's called package.upstream). I don't know anything about the others $VCS-buildpackage tools and if anyone uses them.
- nmu code uploaded by non-maintainers
I'd say that NMUs patches can be directly applied to the Debian repo, at least I won't consider them a problem at all. This because as soon as a package is NMUed, then Debian contains anyway the NMU patch. So, if the official maintainer doesn't like the patch it can revert it. This avoids code/repo duplication, too.
- proposed code not uplaoded, for review
I'd prefer the patch posted to the mailing list, but this is personal.
At least git and hg have the ability to hardlink repository data. A Mercurial repo can also be updated to its null revision so as not to have a working copy (or, actaully, an empty one). So we could create automatically a dozen of repos for each package basically at no cost (things like nmu-l10n).
Especially for l10n, if we coordinate the work with the l10n team I see no hurt in giving them write permissions to the Debian repo (similarly to the NMU situation I explained above). Since we use DVCSs, people can have their personal repositories on Alioth as public_VCS, which can be easily downloaded. Yes, I'd prefer less repos in the group and, if needed, more personal repos.
We may also have repos or tags to make it easy to track Debian releases.
Mmm, can you elaborate on this? I see the need for a Debian release specific repo only in case of backports (because usually you need to change the dependencies and maybe patch upstream).
An upstream repo would only be needed if we don't use upstream's DVCS, actually.
As I already explained for darcs, the upstream repo is necessary to use darcs-buildpackage (which is optional, but helps).
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@...>
+1
Any other opionion except Pierre and me? Thx, bye, Gismo / Luca
Scribit Luca Capello dies 18/10/2007 hora 21:52:
- proposed code not uplaoded, for review I'd prefer the patch posted to the mailing list, but this is personal.
That or on personal repos, yes. That's clearly the prefered way with a DVCS.
Especially for l10n, if we coordinate the work with the l10n team I see no hurt in giving them write permissions to the Debian repo (similarly to the NMU situation I explained above).
Wouldn't it be better if the l10n team needn't do NMU? That is, if they provide us with the patches, and we do regular uploads with them.
We may also have repos or tags to make it easy to track Debian releases. Mmm, can you elaborate on this? I see the need for a Debian release specific repo only in case of backports (because usually you need to change the dependencies and maybe patch upstream).
Having a branch for stable may be useful if security fixes are applied, as well as for backports. Tags would also probably be very good. For example, in my repos, I tag every upstream and debian version with its version, so you can do "hg up 1.0-2" to have the source code from which 1.0-2 was built, and "hg up 1.0" to have upstream-only source code... Tags with release codenames could be good, too. So to see what is the code of current testing for some package, you'd do "hg up lenny". The latter may not be easy or even possible with all DVCSes. It's trivial to have a moving tag in Mercurial, I read in Git's documentation it's complicated by design (Git developers consider a moving tag a bug). Quickly, Pierre -- nowhere.man@levallois.eu.org OpenPGP 0xD9D50D8A
participants (2)
-
Luca Capello -
Pierre THIERRY