Created attachment 103955 [details] sample file numbering has incorrect line spacing, same on page 47 [reg in 4.2] Steps: 1) Open attached file 2) Look at the numbering after the heading 'Windows Azure' Tested in 4.3.1 on Linux. Regression that begin in 4.3.x.
Created attachment 103956 [details] Word 2013 VS LibO 4.3.1
Please ignore 'numbering has incorrect line spacing, same on page 47 [reg in 4.2]' in the description.
repoducible with 4.3.0.4 under Win7x64 not reproducible with Version: 4.4.0.0.alpha0+ Build ID: 8dc2ab47b9e5ef0ff381575195a36ceec8789ef1 TinderBox: Win-x86@42, Branch:master, Time: 2014-08-02_23:22:41 hence FIXED in 4.4.x master RESOLVED WFM
As it is a regression that was introduced in the 4.3.x branch, i think it should be fixed in the same branch.
as said in Bug 82101 the correct status is RESOLVED WFM. the 4.3.x branch is in the early days so maybe it will be backported one day.
I do agree with you about the 4.2 bug, but WFM isnt a suitable status that will get any attention for a possibility of a backport, especially when 4.4 master has only been a month or two old.
the only thing you can do is: 1- dig bugzilla looking for a similar bug which was fixed by a developer, identify the committ and ask backport 2- do a retrospective bibisect of the 4.4.x branch and find the exact committ that reverted regression, and then ping the developer asking for backport this are the only way you can obtain a backport but remember that not every fix is technically backportable. regarding the status, let's ask Joel what he thinks about it. the RESOLVED WFM status is usually use in these cases, maybe we should consider adding a whiteboard status for these situations where a bug is fixed in master without knowing the committ (WFM) and we are interested in backport. we already have bibisectRequest, maybe we could have backportRequest as well. anyway the best thing is to identify the committ with one of the methods described above
Well couple things: 1. Try on daily 4.3 to see if it was in fact backported 2. This early in the release cycle we should be trying to backport everything (or nearly everything). Usually developers are doing this. As for yet another whiteboard status - I understand the need but I'm not a huge fan of adding yet more (when we've just added a few and we still aren't being consistent). bibisectRequest should get us there also but in these cases we should definitely check daily 4.3 to see if it was before spending the time doing bibisects which are time consuming for everyone. If this one is still not in 4.3 daily please leave a comment with that info and then ping me direct (shoot me an email) and I will try to bibisect it.
Thanks for chiming in Joel. I have just retested against the latest 4.3 and it seems its in there as well.
Migrating Whiteboard tags to Keywords: (BibisectRequest, filter:rtf) Remove redundant 'rtf_filter'. [NinjaEdit]