Re: libgtop string freeze breakage

[Christian Rose <menthos gnome org>]

tis 2003-10-21 klockan 14.28 skrev Bastien Nocera:
> > > There has been an unannounced string freeze breakage in the string
> > > frozen libgtop gnome-2-4 branch.
> > > 
> > > This seems to be the commit in lib/read.c, lib/read_data.c, and
> > > lib/write.c that caused the three unannounced string changes:
> > 
> > Bastien, please let me know if you can sort these changes out, I'd like to
> > include your gnome-2-4 libgtop work in 2.4.1 if possible (and as suggested).
> > If you have time in the next 24hrs, that would be really good. :-)
> 
> String breakage? The string freeze is over AFAIK.

Since when?

I think a certain amount of common sense is applicable. The fact that
2.4.0 has been released doesn't mean that all freezes are suddenly
lifted from the stable branch. What would then the point be in
having a stable branch?

The hard code freeze is in fact temporarily lifted from the stable
branch, but the hard code freeze being gone does certainly not equal all
freezes being gone. The UI freeze is still in effect, and the UI and the
string freeze are closely related.

Also, a good rule of thumb is probably to ask before doing any change
that could affect any potential freeze if one is unsure about whether
the freeze is still in effect, and assume it's still in effect
otherwise, unless explicitly stated as lifted from the stable branch.
Freezes on branches quite naturally aren't something that magically
disappear the moment they are not repeatedly spoken about anymore or
otherwise vocally enforced. Anyone that would in fact believe that
clearly has misunderstood the purpose of freezes to begin with.

The whole point of branching after all is to "leave the freezes" on the
branches and continue on with anything else on HEAD, so it's a pretty
sure bet in general to assume a branch is frozen

But going back to the string freeze, the situation for post-.0 has been
explained previously: 

http://lists.gnome.org/archives/desktop-devel-list/2003-September/msg00384.html
http://lists.gnome.org/archives/desktop-devel-list/2003-September/msg00392.html
http://lists.gnome.org/archives/desktop-devel-list/2003-September/msg00405.html
http://lists.gnome.org/archives/desktop-devel-list/2003-September/msg00406.html

Judging from these answers, we're still in UI freeze, and traditionally,
UI freeze and string freeze have been closely related. From Jeff's mail,
however, it seems you have green light for fixing bugs that are of the
"previously used message that wasn't gettextified" kind and typos.
However, you still need to notify the translators. That didn't happen in
this case; translators weren't told anything at all, which certainly
doesn't make any translators happy or make them feel that their work is
respected.


> Run that if you fancy:
> cvs update -j1.14 -j1.13 libgtop/lib/write.c
> cvs update -j1.15 -j1.14 libgtop/lib/read_data.c
> cvs update -j1.16 -j1.15 libgtop/lib/read.c
> cvs update -j1.400 -j1.399 libgtop/ChangeLog

I would prefer if you could revert your changes from the branch at your
earliest convenience.


> In all cases these messages are never shown anywhere, because no
> supported platform seems to use the daemon.

That may be the case, but translators really have no way to doing any
subjective differentiation in messages this way. That's not the way it
works. Either the module is in the GNOME Desktop and Developer release,
and all its messages in its stable branch are frozen, or it's not.


Christian