Christian Rose schrieb:
ons 2004-07-07 klockan 02.10 skrev Bernd Groh:
>>>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?
No it's not.
And it's not the case that most of the time it rains in the desert
either. Yet, you'll still see that most houses in the desert have
waterproof roofs. Why is that? If we use your logic, this thing with
having roofs would be totally unreasonable, or imply that it rained
often in the desert.
It's that way because we know for sure sometime it's bound to happen,
and the drawbacks of not having the protection are typically considered
more important and have more impact, than the benefits of not having the
In any case? Let's say I know it hardly ever rains, and I don't really
have enough money to do both, put a waterproof roof on my house and feed
my family. Am I really to chose the waterproof roof, given I know it
hardly ever rains? It's all about making the most with the ressources
you've got, isn't it? Of course, if I've got enough ressources, I'd
defnitiely put a waterproof roof on my house, completely agree.
It's the same with CVS access. No, most commits are perfectly
when someone commits a bad or broken translation, it often wastes other
contributor's time and to a significant extent ruins their effort in the
Do not disagree, just the same as with above.
>>>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.
FWIW, in Fedora for translators there is no distinction between HEAD and
stable releases. It's all the same. Everything committed will be
packaged in a product at some point, sometimes later, sometimes *very*
True. I didn't really relate that comment to translations, given the
comment I responded to wasn't related to translations at this point either.
And usually it's impossible to know exactly when. Even if we know
rough schedule, maintainers can decide to package sooner or later, and
there can be a large, and usually in advance unknown, difference in time
between the first and the last one.
>>This is even more the case with translations since the code
>>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?
Why should we have roofs on or houses even in areas where it hardly
rains? Why does my car have crash zones? It surely must imply I'm a bad
If it is up to you to either get a good car, or one that'll do for what
you need, and still allows you to feed your family, would you really get
one that is better and more safe? Because it protects you, while your
family starves? Yes, of course, if you can afford it, if you have enough
ressources, why should you not get a safer car? But if you don't have
the ressources? Now, given you do have the ressources, and it is no
question to you to get the safer car, would you expect everyone else to
get the safer car too? Regardless of whether they can afford it or not?
Cars didn't use to have crash zones. Does it automatically imply
are worse drivers nowadays?
No, just as it doesn't imply that people who can't afford safe cars are
any worse or better drivers than people who can afford safe cars. If
safe cars are really that much better, why isn't everyone driving a safe
Ok, enough of making fun of the funny logic; let's get to some of
real, hard reasons free CVS committing without prior review is for the
most part a very bad strategy:
Were you making fun? I didn't think so. I thought you were trying to
illustrate some of your points with certain analogies, all missing on
Whether you can do something or not,
is dependent on the ressources you've got.
1) If the po file has syntactic errors, the software build will
This will make software maintainers, many other contributors, and
testers *very* unhappy.
You mean the po-format, which should be taken care of, if you, for
example, use KBabel. Ok, agreed, would make me *very* unhappy too. I
believe a pre-commit step to simply check the format is ok should
suffice. Good idea.
2) If the po file has other problems, such as bad translations, it
go undetected for a potentially long time.
Why? You mean once it's in cvs, the maintainer is no longer willing to
look at it? But s/he'll only look at it if it's in her/his inbox?
Bad translations can be an as bad show-stopper to the end user
perception of product quality as many other bugs, including crashes.
Thus, just because the product doesn't crash, it doesn't mean that's all
there is to QA. Far from it.
3) Prior reviewing is often a lot more likely to get done than post
reviewing. Most people don't consider reviewing to be fun in itself, but
if you know that there's a commit pending the review, you at least have
an incentive to do the review, in order for the commit to get done.
Ok, I'll take that point. But at the same time, you will have to
acknowledge that sometimes, maintainers just commit a file without
looking at it, cos they want to get it in, but don't have the time to
look at it right now. In which case, there was a bottleneck for no
In practice, it's thus very difficult to get volunteers to do
reviewing, especially if they would have to figure out themselves that
the commit happened in the first place, and how to get the file to
review themselves afterwards.
If there's a maintainer, s/he'll be notified of the commit, and even of
the module being in QA. But, are you really saying that, in general,
maintainers don't know how to do a cvs diff? Well, if that really is the
case, then maybe we have to do something about it? I'm all up for
getting maintainers up to speed on everything that relates to the
management of translations, and I believe they should know all these things.
4) Many teams have public mailing lists. This is a natural place to
reviews on, since anyone can do a review, and the review doesn't depend
on a single person having to do it. Still, many problems are likely to
Thus there's not necessarily the "getting stuck in somone's inbox"
problem you're talking of.
Well, as said, if there's a certain process already in place for a
certain group, then I'd like to support it. I have nothing against
putting up a po-file for review, as long as I know there are people
reviewing it. I do not in the least object to things getting done this
way. However, that doesn't make me change my opinion about the just
implemented system being a good thing and helpful.
5) If someone commits an erroneous file, someone has to notice it.
no, tracking CVS takes a nontrivial amount of time and effort. Not
everyone is employed by a company to deal with this kind of things on
their job time. Not many people consider having to constantly monitor
other people's commits and check them afterwards for errors a fun thing
to spend their time on.
Yes, and that someone may as well be the end-user who files a bug
report. I don't think anyone expects us to be perfectionists, as long as
we respond to bugs and fix them as they occur. If you do have a hundered
hours of free time on your hand (if anyone does) you're invited to make
the translation as good as possible. However, we have to live with what
we've got. In the end, it's all about how much ressources you've got.
And if you haven't got enough, you just have to trade off some quality.
I don't believe that ressources can be created out of nothing and people
volunteering their time, can be *made* to volunteer even more. Yes, I'd
like to encourage them, but putting mandates on volunteers is, IMO, not
the smartest thing to do, and could, in effect, have the opposite
effect. And yes, I acknowledge that I could be wrong.
And true, not many people consider having to constantly monitor other
people's commits and check them afterwards for errors a fun thing to
spend their time on, but now at least maintainers know that other people
are working on their files, which wasn't the case before. Also, not many
people consider having to review po-files and commit them afterwards a
fun thing to do, and in how is that any different? What makes it so much
more fun having the po-file, reviewing, and then committing it?
6) If someone commits an erroneous file, someone has to fix it. And
reverting things in CVS takes a nontrivial amount of time and effort.
Not everyone is employed by a company to deal with this kind of things
on their job time. Not many people consider having to revert other
people's stuff a fun thing to spend their time on.
Well, it's just in case it's a rainy day, I doubt it'll happen very
often, most of the time, so I believe, you'd just fix some strings and
commit, without even requiring to roll back anything. And I do believe
it won't happen anymore than before. If someone commited an erroneous
file before, somebody had to fix it. In how is that any different now?
If someone sends an erroneous file, somebody has to fix it too. I'll
take your point that people are more likely to fix things that are in
their inbox than already commited to cvs, but given they can commit the
file without looking at it, I don't see that big a difference. However,
and I said that before, if a group wants to do things this way, and
really only commit once the translations are reviewed and stamped, I
want to support that too.
Out of these, the points 1, 2, 5, and 6 should be obvious to anyone
any level of QA experience in free software.
Well, maybe I simply lack QA experience? Maybe I really don't understand
that a safer car is better than an unsafe car? But maybe, just maybe,
there are other issue to consider than a safe car being better than an
unsafe car, like, for example, whether you've got the ressources to
afford a safe car?
Fedora-trans-list mailing 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