Re: request for freeze breakage - gok

[Bill Haneman <Bill Haneman Sun COM>]

On Wed, 2004-09-08 at 12:34, Murray Cumming wrote:
> > module: gok
> > maintainers: David Bolter, Bill Haneman
> > bug: http://bugzilla.gnome.org/show_bug.cgi?id=152086
> > patch: http://bugzilla.gnome.org/attachment.cgi?id=31390&action=view
> >
> > We've discovered that our gok-with-references.schemas.m4 file is busted.
> >
> > This doesn't matter for a casual install from tarball or cvs, but
> > matters if a developer or translator decides to update the schemas.in
> > file (as per the somewhat buried directions) however it means that 17
> > strings are erroneously going unmarked; fixing the m4 file will cause
> > the strings to become marked.
> 
> What will the user experience in this case? Or, what does the bug look
> like in practice?

1) User who does 'make install': no build impact, but 17 strings go
untranslated for end users.

2) User/maintainer who manually runs m4 (as documented in
gok-with-references.schemas.in): build breakage and/or runtime breakage
after manually regenerating the .schemas.in file.: GOK won't run
afterwards.

#2 is not a common case; by that logic, fixing the macro is both
low-risk and low-urgency.  But since it's a build-ish scenario, we
thought release-team should be informed of the issue.

Personally I think there's no harm in fixing the macro, since in
scenario #1 the change to the macro will have no effect, since the
patched file isn't touched at all, and in scenario #2 we go from 'very
broken' to 'missing a few translations'.

> 
> > If the i18n team thinks the strings can go in now, then we request
> > release-team permission to apply patch:
> > http://bugzilla.gnome.org/attachment.cgi?id=31390&action=view

> You don't seem to have CCed the i18n people.

I see that David cc'd gnome-i18n gnome org, above.  Is that not the
correct alias?

My opinion is we should fix the macro in 2.8.0 (very low risk), but
leave the generated .schemas.in file untouched in 2.8.0, so that the
string count/translation stats aren't messed up.

I think it's then up to the i18n team as to whether we should re-gen the
.schemas.in file for 2.8.1, as this would result in the addition of 17
marked strings (which were unintentionally going unmarked as a side
effect).

- Bill

> > If the i18n team thinks patch should go into 2.8.1 instead (which is
> > what we request), then we will apply the patch post-2.8.0.
> >
> > If the release-team thinks the broken m4 macro is a 2.8.0 risk, we can
> > apply an alternate, temporary patch which simply reverts/removes the
> > broken macros such that the impact on the current string situation is nil.
> >
> > [note: that the m4 change came in from the i18n team (Sun i18n team that
> > is) but that it was improperly applied due to a merge failure, and since
> > we didn't run m4 manually the problem did not surface when the patch was
> > initially introduced (before string freeze).]
> 
> 
> Murray Cumming
> murrayc murrayc com
> www.murrayc.com
> www.openismus.com