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

Re: Annoucement: New translation status page is installed



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




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