> I wanted to discuss this topic Christian Perrier, it's not 100% clear yet. > Git is probably a bit more difficult to handle for people not familiar > with distributed revision control system. If we commit to the same branch all the time, I don't think so. That means using 3 commands for checkoutupdate/commit and nothing more. Anyway, translators who were directly committing were already the most experienced ones and they were handling SVN commits quite well. > There are various possible workflows: > - people can push translation updates in the main repository directly This has my preference. > - we can have a single repository dedicated to translators and the > developers will regularly pull updates there (this reduce the chance > that a translator accidentally mess up the main repository) That would mean that someone takes care to update the i18n repo with changes and, therefore, keep self updated with what is to be integrated or not, then generate POT files from that. In short, that repo will mimic the trunk, so I don't really see any need for that: we can just have translators committing to the "trunk". > - translators only use git to get the latest tree and send patches created > by git-format-patch (and a dpkg developer uses git-am to apply them > quickly and efficiently) Too messy. Will not work..:-) The important point for translators is having a solid and very easy to identify reference. This is indeed why distributed development makes our life hard: when you will merge changes from a developer's branch, *this* is the time we should update translations but that will often be the time where developers will release the package. In short, translators will always lag behind the developers and we cannot anticipate changes. That is the main difference with centralized development but, well, we'll have to cope with this. What *will* be very important are string freezes: when dpkg releases are prepared, the following shoudl happen: - update trunk - regenerate the PO files (making *this* easy to do would be great.....which is *not* the case with autoconf stuff because one has to run autoconf and all these magic and obscure things are plain mistery, at least for me) - warn translators and give them a reasonable delay (10 days) - release This is particularly important when Debian releases are being prepared, of course, but here, the fact that dpkg is frozen much before the general freeze is a good help for us. But, of course, the final freeze MUST include a string freeze.
Attachment:
signature.asc
Description: Digital signature