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
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
