Re: ESC call Thursday 16:00 central European time ...

On 08/10/14 17:12, Kohei Yoshida wrote:
> On Wed, 2014-10-08 at 15:06 +0200, Jean-Baptiste Faure wrote:

> >  as if this
> > former behavior was completely broken.
>
> There were those users who believed that the former behavior was
> "broken", and fought tooth and nail to get that "fixed".
>
> >  Ok, it is not perfect but many
> > spreadsheets are build on this behavior since many years. 
>
> Which I was not even remotely aware of, but then I'm not aware of 100%
> of how our users use our software.  I get surprised every single day.
>
> > With 4.3.2 and
> > 4.2.7 all these spreadsheets do not work anymore 
>
> By the same token, the "fix" also allows those users wanting the fix to
> start using Calc to fit their needs.

so there are 2 different behaviours of the feature, and users can't
agree on which one is "correct".

> > The problem is not the original patch (the patch for the master), it
> > works perfectly and Kohei did a fantastic job with it and its
> > complementary patch which added the configuration option allowing the
> > choose between the new behavior and the former. Thank you very much for
> > that.
> > The issue is in the decision to backport the first patch without the
> > configuration option (fdo#81309 only) to 4.3.1 and 4.2.7
>
> It was because of the translation requirement that the backport would
> add.

do we really have to make ourselves slaves to un-changeable processes
like "there shall be no new strings in bugfix releases", no matter the
circumstances?  i'd say we leave that kind of attitude to other
projects.  why don't we make a more pragmatic decision here: let's
decide that in this _particular_ case, the one additional string that
may be untranslated and show up in English in 4.2.7 is a lesser evil
than offering only one of the behaviours that users want
functionality-wise; then we don't have to choose which group of users we
have to annoy with a regression.