One more step at being the universal operating system: getting Debian to space:
Specifically, the International Space Station astronauts will be using computers running Debian 6.
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.
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.
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 (:
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.
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.
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.
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.