[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: New Git repository

> 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

Reply to: