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