Annoucement: New translation status page is installed

Bernd Groh bgroh at redhat.com
Wed Jul 7 00:10:28 UTC 2004


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 at 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/






More information about the trans mailing list