The problems with free CVS committing

Bernd Groh bgroh at redhat.com
Thu Jul 8 01:27:54 UTC 2004


Christian,

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
>protection.
>

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 fine. Yet,
>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
>affected release.
>

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*
>soon.
>

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 the
>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.
>

Completely agree.

>>>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?
>>    
>>
>
>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
>driver?
>

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 people
>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 
car?

>Ok, enough of making fun of the funny logic; let's get to some of the
>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 
crucial point:

    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 break.
>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 will
>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.
>

Completely agree.

>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 
particular reason.

>In practice, it's thus very difficult to get volunteers to do post
>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 have
>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
>be catched.
>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. And
>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 no,
>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 with
>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?

Regards,
Bernd

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