Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


Hi Michael,

Michael Meeks wrote (20-02-12 17:13)

On Mon, 2012-02-20 at 15:22 +0100, Cor Nouws wrote:
Winfried Donkers píše v Út 14. 02. 2012 v 07:44 +0100:
Can this patch be pushed to 3.4 and 3.5 branches as well?
The patch addresses problem that go way back in time (pre-LibreOffice at least).

        :-) it is some great work Winfried. For 3.4 I suspect it is rather out
of the question, that is in some deep freeze mode now I think and all
the ultra conservative guys who prefer bugs they know, to potential
fixes they don't know use that. For 3.5 there is more hope.

Yes. But since 3.5.1 is so close and there are issues that IMO are more important ( ;-) ), I guess lagging this to 3.5.2 is reasonable.
Wouldn't that bring down necessary reviews back from three to two?

Jan Holesovsky wrote (14-02-12 14:47)
The problem is that it is partially a feature, and introduces new
strings :-( - so as such, it would be better to wait for 3.6, sorry for
that.

        It is indeed an issue.

As discussed last week on IRC, I would love if it were possible to have
this patch included in at least 3.5.x

        So - we'd need approval from the translators - can you go and persuade
them Cor ? We might also want a write-up of how bad the bug is that it
fixes, and/or how many people it impacts. Then we'd need triple code
review for the new feature - you'd need to find and/or persuade another
three guys to read this carefully.

I could ask the translators.
But on the other hand, I would not have dared to propose this here, when there are no precedents. It would not be the first time that (few) string changes were introduced in a minor release for some good reason.

Now on IRC we also noticed that the patch is huge>  thus expensive to
review.
     (  80a72c4cc7edc6b4c0b88d841500617cd733cbf7 1.2 MB )

        Quite :-) but review also involves testing, and how many people have
these labels, and/or even understand the issue well enough to do that ?
Have you done a lot of testing yourself Cor ? perhaps that'd help give
more confidence.

I have not been able to find a nightly build recently (last months) for Linux x86. Setting up a build locally here may be possible somewhere the next weeks. But I could try a nightly build on windows.
On the other hand: the labels definition wont be a big deal as I wrote.
The worst that could happen here, is that a particular type of label maybe fails, and that can always be repaired in an installed version.

As written in my previous mail: lines with code that does something more then setting properties, defining stuff are really few.

But of course, I'm willing to do some testing, also with new code old label definitions and such. Targeting for 3.5.2 gives some time for that.

        Anyhow - I don't see a special case for bending the rules of triple
reviews, nor a reason to refuse it if it gets that widespread
support :-) it's a nice fix.

Thanks, that sounds encouraging.
As written: going for 3.5.2 means two reviews needed?!

Cheers,

--
 - Cor
 - http://nl.libreoffice.org


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.