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...