Re: Here we go again *SIGH*



>> The responses from the developers indicate quite clearly that they
>> are not satisfied with the methods of string freeze.
>> Presently a number of developers, are deliberately breaking the
>> string freeze and thereby creating trouble for translators.
>> The argument seems to be: "We break string freeze because we can".
>
> I think it's unfair to say developers are using this argument or even
> that they're deliberately breaking the string freeze. If you look at the
> breaks, we have the following situations:

Well, that was sort of the same way I read Johns e-mail

Please, be more polite. I don't know about you, but I have a real life
and a real job. Unfortunately I don't have all time I wish to work on
GNOME, so, I do code after string freeze, yes.

Note that we do not belong to a perfect world. Go to do your
translations and let developers do their job.

how do you read it?

Anyway John. Yes, I have a real life and a real job, thank you very much, and I am just as pressed for time to work on GNOME as everyone else. The only problem with the, "Go do your job and I'll do mine" is that if you don't do yours after the play-book that everyone agreed on, you are going to make my job more difficult.

>
>  + the string was not marked as translatable.
>   => we want the break anyway, since it can only make the situation
>      better.

This one is funny, since it is not even really a string freeze break. That _sometimes_ means that people are a lot more casual about it "I'm not breaking freeze, I just forgot to mark it", despite that fact that for translators the punishment is just a big as with a real freeze break. Also

>  + the developer asked for permission before committing.
>   => this was the decision of the coordination team to accept the
>      break.
>
>  + the developer didn't ask for permission, but it was approved
>   afterwards.
>   => this is bad and the developer should be told so. But the result is
>      the same as the above case.
>
>  + the developer didn't ask for permission, and it was rejected
>   afterwards.
>   => this is bad and the developer should be told so. The break gets
>      reverted. (if it doesn't get reverted, please tell the release
>      team)
>
>  + this is needed for a really really really important bug fix (eg,
>   related to security)
>   => it doesn't happen often since it's really an exception, but in
>      such cases, the opinion of the coordination team is bypassed (but
>      the coordination team would likely approve such a change anyway)
>
>  + the module does not follow the GNOME freezes (eg, gtk+, glib)
>   => not a lot we can do, except ask the maintainers of such modules to
>      think of translators (and I would say they do)
>
> I don't think developers break string freeze because they can. When they
> do so before asking for permission, it's mostly because they forget
> about it.

If I just "forget" about the procedures I am supposed to adhere to when I use SVN account, developers will have my head on a plate. If I just "forget" about the release schedule for GNOME that just means that my translations doesn't make it in, and the Danish users will suffer.

I agree and understand that all the break situations listed above are valid and necessary. Where I get a little annoyed is when I get the idea from a string freeze break, that the particular bug could just as easily have been fixed one week earlier, outside of the string freeze period (which is always the case with the "I forgot to mark this for translation"-breaks (even though its not a break)). Please note, that I'm not asking volounteer or paid developers to work more, I'm just asking them to parrallel shift their efforts 1-2 weeks. We have all have hard deadline at release, developers have quite a few extra deadlines during the cycle, but please don't use the string freeze break procedures as a way to make the string freeze deadline elastic at the expence of the translators. That's all I'm saying, as politely as I can.

Best regards Kenneth Nielsen


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