Jeremy,
Jeremy Katz schrieb:
On Tue, 2004-07-06 at 17:51 +1000, Bernd Groh wrote:
>What is the major drama about having the changes in the cvs? If the
>translation is no good, you can always roll back. I prefer to have the
>changes in cvs, at least then everyone can have a look at the most recent
>changes without having to talk to the person who has the po-file in
>her/his inbox. A commit is not a final thing, it can easily be undone.
>
>
That depends on when the commit is done. If the commit is done shortly
before a freeze of some sort, there's a good chance that it _can't_ be
easily undone. It first requires getting the maintainer of the module
to respin when they thought they were already done. A lot of the QA
which has been done at that point then also needs to be at least checked
to see if it needs to be reverified or not. And if it's not noticed for
a day or two (for whatever reason, that's not unreasonable) and you then
hit the point at which the tree is frozen, then getting it changed is
that much more difficult.
Well taken. And I don't really have anything against QAing before a file
is commited, iff there is a maintainer who is happy to QA it. If the
maintainer just doesn't have the time, given it's all voluntary after
all, and good translations are simply sitting in an inbox, rather than
getting into the packages, than that's a situation I'd like to avoid. Or
is it really the case that most committed translations are bad?
> Or do you always
>make sure that your most recent software changes work before you commit
>them? How do you do that with a larger addition? Do you wait till it's
>finished and not keep track of changes for days, but commit a whole
>bunch of changes at once?
>
>
The goal has to be to keep CVS working at all times. Otherwise, you
kill testing. So yes, I tend to try to make sure that either a) my new
stuff works or b) at least doesn't break anything new (perhaps the new
functionality doesn't work, but old things should continue doing so).
For the case that my additions can break stuff that's tested, of course
I do that too. For my own projects, I usually make sure that all my
release branches are working at all time, but I am not that strict with
HEAD, since I don't deploy HEAD.
This is even more the case with translations since the code
maintainers
of a module aren't going to know/keep up with the status of the
translations and so need them to be as "correct" as possible at all
times since there's no controlling when they're going to do a build.
Do not disagree in the least. But why should commited translations by
default be incorrect? And in particular, why should they now be more
incorrect than before? Now at least a maintainer has the chance to see
who is working on a module.
Cheers,
Bernd
Jeremy
--
Fedora-trans-list mailing list
Fedora-trans-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-trans-list
--
Dr. Bernd R. Groh Phone : +61 7 3514 8114
Software Engineer (Localization) Fax : +61 7 3514 8199
Red Hat Asia-Pacific Mobile: +61 403 851 269
Disclaimer:
http://apac.redhat.com/disclaimer/