Re: libgtop string freeze breakage

[Bastien Nocera <hadess hadess net>]

On Tue, 2003-10-21 at 22:17, Christian Rose wrote:
> 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.

I've reverted the changes.

---
Bastien Nocera <hadess@hadess.net> 
Remember the 3 golden rules: 1. It was like that when I got here. 2. I
didn't do it. 3. (To your Boss) I like your style.