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