> On Wed, 28 Jul 2004, Max Bowsher wrote:
>
> > Erik Huelsmann wrote:
> > >>>> Log:
> > >>>> Merge translation updates.
> > >>>>
> > >>>> Merge trunk revisions
> > >>>> r10254,
> > >>>> r10282,
> > >>>> r10409,
> > >>>> r10412,
> > >>>> r10415,
> > >>>> r10418,
> > >>>> r10423,
> > >>>> r10426.
> > >>>>
> > >>>>
> > >>> Some of these (the changes to es and sv) include formatting strings
> and
> > >>> require voting per hacking. Maybe this was discussed when you were
> > away...
> > >>
> > >> I thought by that we meant you couldn't change the argument ordering,
> > >> add any arguments to a message, or change the types of the arguments.
> > >> Not that you couldn't touch something that was used as a format call.
> > >> Now if you change a %d to %ld then you'd be violating that. But I
> don't
> > >> think adding:
> > >>
> > >> +msgid "Unsupported FS loader version (%d) for fsfs"
> > >> +msgstr "Aplique RA binariamente incompatible (versión %d) para
> ra_dav"
> > >>
> > >> violates thats. Am I missing some case where adding that would be
> bad?
> > >
> > > I'd love it to mean that. I think the idea is that the review and
> voting
> > > process should make sure that no strings slip through which do change
> > > parameters or parameter ordering.
> >
> > I think the case illustrated by the above example is perfectly ok to
> merge.
>
> Ofcourse, isnce it is correct. But that's the case with all correct code
> if it qualifies for other reasons.
>
> > Any committer doing .po merges to branches has responsibility to check
> > carefully that all the strings to merge really do have no format
> specifier
> > changes.
> >
> > To help them, we might consider declaring that any revisions with format
> > specifier changes *MUST* say so in the log message.
> >
> Two steps that are easy to miss sometimes and that will introduce a crash.
>
> In HACKING, we require voting for any changes to strings in the C source
> and we don't allow % changes at all. The .po rule is relaxed so string
> changes (I'm always talking about msgstr strings,msgid is a change to the
> C code) that don't touch % codes can be merged without voting. But %
> changes require voting, since the format strings aren't validated by the
> normal build (because that's non-portable) and they easily introduce
> crashes. GNU msgfmt can validate format strings, so it is easy to make
> sure they are correct. Still people make mistakes and miss this. (I might
> be abnormally sloppy, but you can see a recent commit by me that was just
> comment fixes, shortly followed by a follow-up that removed an extra */,
> so that the whole tree built again...)
>
> That was the idea when I proposed the change to HACKING some month ago.
> Ironically, then, jerenkrantz (I believe) objected saying this rule was
> too relaxed. And now, some people want to relax it even more:-)
Let me start by saying that I think the rule should *not* be relaxed. I
think that I caught attention too late to get the translations up to date. I
know what to do next time we hit a release branch point.
However: Since (and this is an exceptional situation I hope) we will be
restarting soaking with the release of RC2, I figured that puts us back to
the point where the branch is created. Next to that, I run the status mailer
script daily on the branch until we hit 1.1.
Given the above two facts and the fact that what I recognise that what I did
can *never* happen after the start of the soaking has started, I hope that
I'm forgiven this once.
It would be truely a shame to have to do with the quality of the
translations pre-10429 for the next half year or more...
bye,
Erik.
--
NEU: WLAN-Router für 0,- EUR* - auch für DSL-Wechsler!
GMX DSL = supergünstig & kabellos http://www.gmx.net/de/go/dsl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 29 11:52:36 2004