Category Archives: LibreOffice

The commit police: learning for recent reference mistakes

Continuing the previous post about commits and bugs, I’d like to review some mistakes I saw recently. Mistakes do happen, but mentioning them here is meant to teach others and hopefully to reduce similar ones in the future. This post isn’t about shaming the authors/commiters. Also, the points I highlight are what I consider as a mistakes or problems, other people might think differently.

  1. Mentioning two bugs in one commit message, which our system doesn’t support right now. So the second bug doesn’t get the commit notification, and that should be done manually (example: commit 2933935 and fdo#53278).
  2. Referencing gerrit changes as part of the commit message (example: commit 87f185d). Giving references as part of the commit is great and helpful, but I would prefer to see the reference to the actual commit and not to its review process. This is meaningful when you search the log. If the followup change is suggested when the first change is still in review it should be combined, otherwise it already have a commit to reference.
  3. Following up a commit, and not mentioning the bug it references (example: commit 87f185d). In this specific case, the we’re talking about a meta bug for translating comments from German to English (fdo#39468), so no harm done. But this important when you want to cherry pick a fix for a bug to other branches and might forget the follow up commits. It’s also relevant to more technical meta bugs (example: fdo#62096).
  4. Referencing a mailing list which reference a commit and a bug instead of referencing them directly (commit 21fea27, fdo#60534). This bug shows very well why correct referencing is important, a commit was made to fix the bug, a follow up commit was done without proper reference, and than the first commit was reverted. No one involved in trying to fix that specific bug knew about the follow up commit as it wasn’t documented anywhere.
  5. Referencing bugs though full bug URL instead of the right format (example: commit e1f6dac). Also the bug is referenced in the commit in the body of the message instead of the first line (header) which is more visible.
  6. Referencing non existing bugs (example: commit 3a4534b). Which got a manual notification in the bug by the comitter (fdo#33091).
  7. Using shortening services URL as part of commit messages (example: commit 86f8fba). There’s no way to know to what the reference is without using the service, which in this case was leading to a post on one of the projects mailing list. There isn’t any problem giving the direct URL to the list’s archive. It’s interesting whether we should link to our URL and is it “OK” to use other external services who also archive our mailing lists (example: commit e83990a).

To conclude, having references in commit message is really helpful, but please reference the right resource to help people find it easily and to let our automated services parse it.

1 Comment

Filed under LibreOffice

The commit police: reference you bugs properly

Besides my RTL work on Libreoffice, every once in a while I just go over the regular commit log to see what have changed. I don’t necessary understand each line in the commit, but do get the general idea from the commit message. Being more dependent on the commit messages makes me review them more thoroughly (hence the topic of this post).

As many projects, Libreoffice has notifications of commits related to bugs reports when the bug number is properly mentioned in the commit message. This is very useful for other developers and also for QA people. After verification of a bug is fixed, I often use the commits listed on the bug report to cherry pick them to an older branch. Going to search for an unreferenced commit isn’t much fun.

One of the things I notice is different ways people reference bugs – from not referencing them at all to referencing them in various ways like linking to the bugs system, just writing the number (without the fdo# prefix) and other creative ways… This is also true for first time contributors, which might not know the standards or the “rules”. When I see such a case I usually put a manual notification in the bug report, and mail the author of doing so. For new or sporadic contributors this is also an opportunity to welcome and thank them for the commit and even encourage future contributions.

I have been asked why aren’t that info on the wiki, so I went looking and found out the info is in the right place under the “Development/GetInvolved” page. The relevant part is:

When you type a commit message:

  • start the first line with a bug reference like fdo#12345, if you have one for your commit (see details below)
  • use the rest of the first line as a concise summary of your changes
  • the 2nd line remains empty
  • and starting on the 3rd line you can explain how and what changes have been made for what reasons.

Thanks in advance and happy coding (:

1 Comment

Filed under LibreOffice

Team work on RTL bugs

After returning from a vacation, I went over my RTL bugs backlog. I missed helping with checking a few patches, so I got left with verifying the fixes done by the KACST guys on master. Last week was dedicated for verifications of the bug fixes, even found a regression and reverted the commit after discussion with the author.

Yesterday, I took my time with pushing these fixes also to the 4-0 branch, having them available as soon as possible instead of waiting for the 4.1 release. Total of 7 bugs got pushed, see https://wiki.documentfoundation.org/RTL_Bugs#4.0.3 for the list. I notified the developers, so they’ll know their changes are available to the public sooner than expected (and let the people enjoy their work earlier). All these pushes make sure that master doesn’t have any RTL support superiority over the current stable branch.

In one of the cases I had to do some follow up about the commit, finding another relevant commit. This was merged with a trick Eike taught me a while ago for squashing commits with git rebase. Fridrich quickly helped with verifying that the squash stills looks good, letting me push another dependent fix on top of it.

Leave a comment

Filed under LibreOffice

RTL status for Libre Office 4.0.0

LibreOffice 4.0.0 will be released soon, and it’s a good time to summarize its RTL status. Similar to 3.5.0, the RTL work started with LibreOffice conference in October, showing the current state (see LibreOffice RTL status 2012 presentation) and listing the top problems. The main goal of this talk is to raise awareness to RTL issues and recruit developer to help fix them. This was exactly what happened with fdo#44657 which is about Calc not having a scroll bar in RTL user interface. This way RTL bug #1 for almost a year.

In total, version 4.0.0 has 8 bugs fixed (mainly Calc, Presenter Console and toolbars). In addition it has 5 language specific bugs fixed. Full lists are at https://wiki.documentfoundation.org/RTL_Bugs#4.0.0 and https://wiki.documentfoundation.org/RTL_Bugs#4.0.0_2. Beside working on fixing bugs for the 4.0.0, another focus was put on making sure the fixes are available for the 3.6.x users. This resulted with cherry picking 11 out of 13 bug fixes (part of 3.6.4 and 3.6.5 releases). More fixes are already underway in the master branch, and will also be part of 4.0.1 maintenance release (full list at https://wiki.documentfoundation.org/RTL_Bugs#4.0.1).

Beside thanking the core developers  for their help (patches, code review), I’d like to thank the guys from The National Program for Free and Open Source Software Technologies (Motah) at King Abdulaziz City for Science and Technology (KACST) in Saudi Arabia, which have joined the RTL team during this release, and their effect is well noticed.

Despite all the work done, we still have a share of RTL bugs for the next release, these are the 7 top priority RTL bugs, any help would be appreciated.

  1. fdo#33302 Brackets inverted in rtl text (mac only)
  2. fdo#53030 Calc deletes current sheet, not right-clicked on sheet when trying to delete opposite directionality sheets
  3. fdo#56403 RTL UI: with RTL locales presentations appear with text align to the right instead of to the left
  4. fdo#37128 Writer saves text alignment of RTL paragraph not according to the ODF specification
  5. fdo#44029 docx files with RTL paragraphs aren’t compatible with Word
  6. fdo#43093 FILEOPEN: [docx] MS Office documents opens with wrong alignment and directionality
  7. fdo#56408 Brackets are not handled correctly with mixed English/Latin and Hebrew/Arabic texts

3 Comments

Filed under i18n & l10n, LibreOffice

LibreOffice conference and motivation

Last week, just before the branching of 3.6.4 was the peak of my recent work in LibreOffice. The motivation from attending the conference and working with others lasted long for me with the help of a few collaborations done since (thanks Caolan and Eike). My own patches were approved just in time to make it to the 3-6 branch, which, along other fixes, pretty much makes 3.6.4 a better release to the RTL users in general, and Hebrew users specifically. Things aren’t perfect, but they’re improving nicely (on going status is at RTL bugs wiki page).

I’m also very happy that most RTL related fixes since the conference have been cherry-picked from master to 3-6 branch, so the users won’t have to wait till February for the 4.0 release. Last year I had to wait till the 3.5 release to see some of my work fruits, now I can see them in much shorter intervals.

The motivation and involvement go hand in hand, each enhances the other for me. I’ve started reviewing patches sent for RTL bugs to verify the suggested fixes with private builds and marking bugs as verified when the patches do get accepted. Compering to a month ago, I’m now busy with helping the developers do their part instead of “just” reporting problems. Seeing things go forward (and helping them do so) is much more motivating than waiting for someone to pick the bug report and try solve it.

I hope having fast response to their code changes is also motivating for the developers, in that case everyone enjoys the collaboration.

Leave a comment

Filed under LibreOffice

How I got an extra value from my flight ticket to libreoffice 2011

Miklos published about his “LibreOffice RTF import Drawing Objects improvements” which was done to fix my report (fdo#42407). As an anecdote I want to mention that he test document was my flight ticket to the LibreOffice conference in 2011.

So I feel I got an extra value from attending the conference in the form of having a this RTF compatibility implemented. In addition, Miklos fixed an import problem with Hebrew with these old documents (fdo#56512) – double value. Miklos – I owe you a drink (:

I’m not sure if I should thank the traveling company for working with such old software which produced the old formatted RTF files, but in any case, it turned out to be a good thing.

Leave a comment

Filed under LibreOffice

LibreOffice conference 2012 (day 2)

I’ve started the morning with the easy hacks for non developers talks, which for my opinion lacked some code related tasks that even non developers can do like fixing translation problems in the source (in the English strings), fixing some simple logic bugs which doesn’t require reading complex code (e.g. traversing records and first/last special cases). The other options mentioned in the talk aren’t less important, but I think people shouldn’t be afraid reading/touching the code to some level even with very limited coding skills.

Later I’ve used Rene’s 3.7/master builds for Debian to verify two RTL bugs (fdo#43210, fdo#44925) fixed by the Motah guys from Saudi Arabia. After the verification, I pushed the changes to the 3.6 branch (should appear in 3.6.4).

Katya, which I’ve met in the last conference, told me see watched my talked remotely, and took interest in RTL ui forcing right alignment to non aligned text. While reproducing the bug on her computer we were able to narrow the problem a bit, to be related to the locale and not only to the RTL interface. Till the end of the day she’d identified the problem in the odp file and I hope a fix will be available by tomorrow.

Jan (kendy) had a good progress with fdo#44657 (RTL problem #1). Checking the fix is quite confusing, and we had to use two laptops to understand and compare the right and desired behavior. Hopefully this problem will end soon, which will make coming to the conference worthwhile (as for the RTL status and efforts).

Later I started working on moving the RTL status page from a wiki in Hebrew to the TDF wiki RTL Bugs page in English . By this I hope to get more visibility to the current status, and as a base to collaboration, let others help with RTL more easily.

During one of the breaks I heard Lionel encourages someone to do builds on his own, and I decided that after avoiding this tasks for two years, it’s about time. By the evening I got a build running according to the native build guide in the wiki (which took half the night on my laptop). There are still a few things to learn how to do with this build, but I how to now be more active in testing things without waiting for official Debian builds (which are quite hard when Debian is frozen). Thanks to Lionel for the encouragement.

Leave a comment

Filed under LibreOffice

LibreOffice conference 2012 (day 1)

Most of the day before the conference, and the conference morning spent working and finalizing my RTL status presentation. My apologies to the lecturers whose lectures I attend only physically (sorry, I can’t split my attention too well).

To my disappointment I had very few attendees in the talk, but I can understand the competition, as the other parallel talks were quite interesting. In at least one of them I wished to attend my self (if I could only be in two places in the same time…). Maybe next year we should have less parallel talks (4 tacks is a lot).

To still push some of the RTL issues, I’ve done a private talk over RTL issues for Caolan and Jan (kendy), which was interesting with some feedback. Jan took fdo#44657 on himself, and by the evening he showed me a great improvement in the status of things, so at least there’s horizontal scrolling in Calc with RTL interface.

With the help of Rene, I got master builds for Debian, and would spend the rest of the conference to check some bugs with it.

During the evening dinner and social event I wanted to thank Miklos personally for really improving the RTF support for RTL and Hebrew documents, and he showed me a few of the new stuff he’d done in master/3.7. While working I’ve noticed a few regressions, and I’m glad they were caught early.

Cedric told me that after last years talk, he started to check his features also in RTL interface, which for me was the best feedback on my efforts. Having developers keeping RTL in mind (even only nce in a while) saves a lot of trouble along the road. I would prefer to check and double check features while they’re being created instead of trying to get bugs fixed later on the release process.

Another thing which I enjoyed noticing is the “fresh blood” the GSoC project brings to LibreOffice. I’ve met with Miklos and Eilidh and got impressed with how a successful internship was used as a springboard into a good job. As there almost aren’t any Israelis who take part in GSoC, I’m not used to notice the effect closely.

The event dinner and mingling was very successful for me, I’ve got a chance to talk with old friends and meet some of the new attendees (and even get some technical work done by talking with people)… Thanks again for the organizational team.

3 Comments

Filed under LibreOffice

Taking a vacation from open source

In the last 6 months I’ve devoted a lot of time to the open source projects I’m part of.  I decided to take a vacation from most of the open source stuff I do. This is mainly to balance things better and make sure I don’t feel burnt out. I’m not disappearing completely, but rather shifting into a lower gear and focus on the things I enjoy most regarding open source.

4 Comments

Filed under Debian GNU/Linux, LibreOffice

RTL status for Libre Office 3.5.0

As LibreOffice is approaching its final 3.5.0 release, I’d like to sum up the RTL status for RC1.

So far, 6 RTL related bugs were resolved in the 3.5 cycle (#32530, #34222, #40950, #43790#43793, #44078), and a few minor issues reported directly to the developer’s mailing list got quick responses. Most importantly, the new features of page break and header/footer not only support RTL but actually looks good. During the LibreOffice conference I was suggested to help with these features, providing feedback, and I’m glade the needed attention was given to it.

Besides that, a few l10n and translation issues were solved in the process of doing the Hebrew translation (which also reflects on other RTL languages). At a few cases, these issue because a general l10n issues which affects all the languages.

In general, I found the core developers responsive to mails about RTL support. I’m sure the talk about RTL problems during the conference helped, as well as being more active in the project and having more personal acquaintance with the developers.

That’s being said, RTL support for LibreOffice still has problems, which I hope will be pushed during the 3.5.x cycles (full list at Bug 43808, the rtl meta bug). As to get some focus regarding was is to be done, I’m listing the top problems:

  1. #44657 – RTL UI: Horizontal scrollbar in calc main window is broken
  2. #33302 – brackets inverted in rtl text (mac only)
  3. #37692 – RTL list numbering reverses its direction
  4. #42070 - RTL support in broken in presenter Console extension
  5. #32531 - Incorrect cursor key movement between table cells of different directionality
  6. #104515 - RTL UI: moving active embedded object to the left moves it to the right (reported for OO.org, but verified in LibO)
  7. #37128 - Writer saves text alignment of RTL paragraph not according to the ODF specification

I hoped to have the first two done for 3.5.0, but didn’t succeed in getting them fixed. Will keep trying…

2 Comments

Filed under i18n & l10n, Israeli Community, LibreOffice