Bug 82105

Summary: FILEOPEN: RTF numbering spacing not retained
Product: LibreOffice Reporter: Jay Philips <philipz85>
Component: WriterAssignee: Not Assigned <libreoffice-bugs>
Status: RESOLVED WORKSFORME QA Contact:
Severity: normal    
Priority: medium CC: barta, jmadero.dev
Version: 4.3.0.4 releaseKeywords: regression
Hardware: Other   
OS: All   
Whiteboard: BibisectRequest filter:rtf rtf_filter
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 81234    
Attachments: sample file
Word 2013 VS LibO 4.3.1

Description Jay Philips 2014-08-04 00:51:44 UTC
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.
Comment 1 Jay Philips 2014-08-04 00:52:30 UTC
Created attachment 103956 [details]
Word 2013 VS LibO 4.3.1
Comment 2 Jay Philips 2014-08-04 01:01:14 UTC
Please ignore 'numbering has incorrect line spacing, same on page 47 [reg in 4.2]' in the description.
Comment 3 tommy27 2014-08-04 13:01:15 UTC
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
Comment 4 Jay Philips 2014-08-04 19:14:07 UTC
As it is a regression that was introduced in the 4.3.x branch, i think it should be fixed in the same branch.
Comment 5 tommy27 2014-08-04 20:33:31 UTC
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.
Comment 6 Jay Philips 2014-08-04 23:27:23 UTC
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.
Comment 7 tommy27 2014-08-05 05:16:31 UTC
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
Comment 8 Joel Madero 2014-08-05 05:53:49 UTC
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.
Comment 9 Jay Philips 2014-08-05 08:41:52 UTC
Thanks for chiming in Joel. I have just retested against the latest 4.3 and it seems its in there as well.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.