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

Re: The problems with free CVS committing



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