Re: [patch] fstab-sync mount point names

[Christian Rose <menthos gnome org>]

tis 2004-08-31 klockan 11.39 skrev Kjartan Maraas:
> tir, 31,.08.2004 kl. 09.10 +0200, skrev Alexander Larsson:
> > On Mon, 2004-08-30 at 19:24, David Zeuthen wrote:
> > > On Mon, 2004-08-30 at 19:16 +0200, David Zeuthen wrote:
> > > > Hi Alex,
> > > > 
> > > > This simple patch adds some more heuristics to recognize the mount point
> > > > names generated by fstab-sync. Also, this patch uses the some of new and
> > > > cool icons Jimmac put in gnome-icon-themes. You can find a screenshot
> > > > right here 
> > > > 
> > > 
> > > Attached is an improved version that fixes one leak compared to the
> > > inital patch. Doh!
> > 
> > The patch looks fine to me, but it adds strings, so it can't go into 2.8
> > as is, even with release-team approval. We could probably get the
> > non-stringchanging parts into cvs, as they are pretty simple to review
> > and don't affect stability.
> > 
> > release-team, is this patch ok for gnome 2.8? All it does is recognize
> > some mountpoint names that HAL creates and give them more descriptive
> > icons. (The icons are alreay in gnome-icon-theme.)
> > 
> > For fedora, i guess we'll have the string-additions as an extra patch in
> > the rpm.
> > 
> If the strings are visible adding the patch to the RPM will create
> problems for translations in FC3. I'm not sure what will annoy the
> translators most, having a few more strings to translate in HAL or
> having them untranslated in every installed FC3 system? :-)

I assume the patch being discussed is this one:
http://mail.gnome.org/archives/gnome-vfs-list/2004-August/msg00050.html


> I would be ok with adding them upstream, but that's not my call to make
> I guess.

Kjartan, you're still one of the two GTP spokespersons, so you still
have authority. :-)

My opinion is as follows:

1) We're already more than two weeks into string freeze. The release
schedule, including the string freeze, have been publically announced on
http://www.gnome.org/start/2.7/ for many months. It should be no
surprise to anyone that we're in string freeze, and that this is in
general *not* the time for patches that add or alter translateable
strings. Such changes should either have been done before the freeze, or
be punted to the next development cycle.

2) Still, these strings/messages do not appear to be the most difficult
ones to translate. They're many, but relatively trivial.

3) These strings look highly visible (given that the appropriate
hardware/media exists).

4) If distros pull the "we'll include the string patch anyway" trump
card, we're bad off anyway. String freeze is there to give translators
suitable time to complete the translations. If we reject patches on the
grounds of string freeze, patches that downstream distros are likely to
include anyway, the end result will still be incomplete translations
presented to the end user, and we haven't achieved anything in practice
by sticking to the freeze.
Even though distros are free to include what patches they want, I think
it's sad that the upstream procedure and freezes and their purpose can
be bypassed and twisted that way. One could of course stick firm to the
freeze, and blame the untranslated content on a distro that includes
such a patch anyway on that particular distro, but that won't help end
users on that distro who want and need those translations much.

So, given points 2, 3, and 4 you have my approval for the string-adding
parts of this patch, given these conditions:
A) The patch is applied to CVS as soon as possible, given other
permissions of course.
B) gnome-i18n gnome org will be notified as soon as the patch has been
applied to CVS, and informed that gnome-vfs translations need updating.

Given the above, you have the second string-freeze approval, and two
approvals out of one necessary.


Christian