Second Bug Hunting Session for LibreOffice 5.3

noun_83830_ccLibreOffice 5.3 will be announced at the end of January 2017, with a large number of new features which are summarized on the release notes page: https://wiki.documentfoundation.org/ReleaseNotes/5.3. In order to find, report and triage bugs, the QA team is organizing a second bug hunting session on Friday, November 25, 2016. Tests will be performed on the Beta version of LibreOffice 5.3, which will be available on the pre-releases server (http://dev-builds.libreoffice.org/pre-releases/) a few days before the event. Builds will be available for Linux (DEB and RPM), MacOS and Windows, and will run in parallel with the production version.

Mentors will be available on November 25, 2016, from 8AM UTC to 10PM UTC. Of course, hunting bugs will be possible also on other days, as the builds of this particular Beta release (LibreOffice 5.3.0 Beta1) will be available until mid December.

During the day there will be two dedicated sessions: the first to chase bugs on the main LibreOffice modules between 3PM UTC and 5PM UTC, and the second to test a set of the top 7 features between 5PM UTC and 7PM UTC. All details of the second bug hunting session are available on the specific wiki page: https://wiki.documentfoundation.org/QA/BugHuntingSession/5.3.0Beta1.

During the dedicated sessions, we will concentrate all efforts to chase and reproduce the bugs, in order to confirm and file them in a more comprehensive way. Of course, the more comprehensive will be the bug report, the easier will be for the developers to solve the bugs in time for the final release.

Second ever LibreOffice Hackfest in Italy, with 15 participants

Development mentor Jan Iversen writes:

“Italy has a very big LibreOffice community but with only a few developers, so when LibreItalia had its yearly conference this weekend, we tried to start changing the situation. The second hackfest in Italy was only around four hours – but the time was well spent.

After a short introduction from Marina (Chairwoman of The Document Foundation) our development mentor gave a presentation, explaining how everybody can help LibreOffice. Slides were in Italian, the talk was in English, and comments were in Spanish.

There were in total 15 people including power users, contributors, source code committers and certified developers – a broad range to address. There was less interest in getting a build done, and much more interest in two other aspects:

  • How can we grow a local development community, ranging from people helping QA to “hard-core” developers?
  • The ladder to enter development is too high, so what can we do do make development attractive for new people?

Jan presented our toolbox, which is actually quite extensive. Opengrok surprised everybody. None of the fast developer notebooks could match the fast search times. A search for “jani” took 15ms and was called cheating, so we did another search for “Ponzo” which took just 16ms.

The online editing feature in Gerrit made even the skilled developers look up. We had a longer discussion about when not to use this feature, but everybody saw the clear advantage.

In the end, there was only one question: when do we have a full two-day Hackfest? Osvaldo promised to arrange one in his University during the first quarter of 2017.

No visit to Italy is complete without pizza. LibreItalia arranged dinner in a nice pizza restaurant (sorry, not the typical European style, but real pizza!). It was amazing to feel and see, how big the hospitality is there, and how eager people were to learn.

So in all, a big thank you to LibreItalia for giving me this chance to promote developers. I am sure it will not be last time I visit Italy.”

FOSDEM Call for Papers: Open Document Editors DevRoom

fosdemFOSDEM is one of the largest gatherings of Free Software contributors in the world and happens each year in Brussels (Belgium) at the ULB Campus Solbosch. In 2017, it will be held on Saturday, February 4, and Sunday, February 5.

As usual, the Open Document Editors DevRoom will be jointly organized by Apache OpenOffice and LibreOffice, on Saturday, February 4, in room 4.401 in Building K (from 10:30AM to 6:30PM). The shared devroom gives every project in this area a chance to present ODF related developments and innovations.

We are now inviting proposals for talks about Open Document Editors or the ODF document format, on topics such as code, extensions, localization, QA, UX, tools and adoption related cases. This is a unique opportunity to show new ideas and developments to a wide technical audience.

Length of talks should be limited to a maximum of 30 minutes, as we would like to have questions after each presentation, and to fit as many presenters as possible in the schedule. Exceptions must be explicitly requested and justified. You may be assigned LESS time than you request.

All submissions have to be made in the Pentabarf event planning tool: https://penta.fosdem.org/submission/FOSDEM17.

While filing your proposal, please provide the title of your talk, a short abstract (one or two paragraphs), some information about yourself (name, bio and photo, but please do remember that your profile might be already stored at Pentabarf).

To submit your talk, click on “Create Event”, then make sure to select the “Open Document Editors” devroom as the “Track”. Otherwise, your talk will not be even considered for any devroom at all.

If you already have a Pentabarf account from a previous year, even if your talk was not accepted, please reuse it. Create an account if, and only if, you don’t have one from a previous year. If you have any issues with Pentabarf, please contact ode-devroom-manager@fosdem.org.

The deadline is Monday, December 5th, 2016. Accepted speakers will be notified by Sunday, December 11th, 2016. The DevRoom schedule will be published on the same day.

Recording Permission

The talks in the Open Document Editors DevRoom will be audio and video recorded, and possibly streamed live too.

In the “Submission notes” field, please indicate that you agree that your presentation will be licensed under the CC-BY-SA-4.0 or CC-BY-4.0 license and that you agree to have your presentation recorded. For example: “If my speech is accepted for FOSDEM, I hereby agree to license all recordings, slides, and other associated materials under the Creative Commons Attribution Share-Alike 4.0 International License. Sincerely, Name”.

LibreOffice Community Weeks: Wrapping up

LibreOffice Community Weeks

We’re already in to a new Month of LibreOffice, but in October we ran a series of Community Weeks, looking at what different teams in the LibreOffice project do, and how you can help them. So firstly, here’s a reminder of the articles, and then we’ll find out what effect they had…

Documentation

Development

Quality Assurance (QA)

Design

 

Feedback from the teams

So what effect did the Community Weeks have on the projects? Here’s what each team had to say:

Olivier Hallot (documentation): “The Community Weeks brought more people to the realm we are working in, and I had 3 new people showing up. One is a PhD professor from a university in India, who wrote a page on a set of Calc functions, and asked for more work. Another is a New Zealand national, involved in migrations and support, who is updating our books. I also got someone on IRC, but he did not came back. So overall, the week is positive, but we need people to return after their first contributions.”

Jan Iversen (development): “The week worked well – during the last period 15 people have got their first patch merged, and will appear by name in the 5.4 release notes. I often hear “but I cannot work full-time”, so it is important to realize that while roughly 50% of the changes are done by 20-30 people, the other 50% is done by hundreds of people making 1-10 patches a year. Every change counts and is very welcome! We arrange developers days, when a group wants help, so please contact us at mentor@documentfoundation.org if you need help.”

Xisco Fauli (QA): “There were 4-5 new users who showed up on IRC during the Bug Hunting Session, who may have joined from reading the Community Week posts. Also, we hope both posts from that week will help readers to report better bugs in the future (attaching simpler samples, adding clearer steps, and so forth).”

Heiko Tietze (design): “The campaign was interesting and encouraged readers to follow links to the Design Team Blog. Even if we didn’t get more active people showing up in the design project, comments are always welcome.”

Thanks to everyone who took part. We’ll do more Community Weeks next year, so if there’s something you want us to focus on, just let us know!

Community Week: Development – get involved

LibreOffice Community Weeks

On Monday we had a chat with LibreOffice’s dedicated mentor for new developers, Jan Iversen, and on Wednesday we then looked at some statistics from the development team and the tools they use. Today we finish off this Community Week by showing you how to get involved. Put your coding gloves on and get ready to become a LibreOffice hacker…

Getting the source code

The first thing you need to do is read this page – this is a step-by-step guide, from the primary contact until you have successfully gotten your first patch merged.

The page describes how to download the source code:

  • Git: at the command line, enter “git clone git://anongit.freedesktop.org/libreoffice/core”

This download takes a while, but with that you have access to not only master (the bleeding edge source code), but also are release candidates (e.g. 5.1.6 RC1) as well as old versions. In total this is the source code with history.

Building LibreOffice is a task that takes quite a while, because the suite has approximately 7 million lines of code. The time needed depends a lot on your setup and the operating system. Windows is the slowest, and it is common to see the first build to take 6-10 hours. Linux and macOS are pretty fast: the normal time is 1-2 hours. Remember that the second build is a lot faster because it only builds changes.

Building it

How you build the code depends on your operating system, but our wiki has some guides:

If you have a choice of operating systems at your disposal, we recommend using Linux, where it’s very easy to install development tools and other related software.

Oh, and want to see what a LibreOffice build process looks like? Check out this speeded-up video (maybe turn down your audio before playing it though – the music is a bit loud!)

Start communicating

Once you’re able to build LibreOffice from its source code, it’s a good idea to reach out to other developers – maybe to get help, or ask for pointers, or simply see what things need working on. You can subscribe to the mailing list (see the archives here), but for more immediate contact join the #libreoffice-dev IRC channel on Freenode.

The mailing list and IRC channel can be busy, so there’s not a lot of time for off-topic discussion, but it’s worth introducing yourself quickly (who you are, why you want to help, any specific things you want to work on). If you want to talk to Jan, the new developer mentor, you’ll find him as @janIV on the IRC channel. Or send an email to mentoring@documentfoundation.org.

Start hacking!

We’ve mentioned “Easy Hacks” a few times this week – now we’ll explore them in detail. Easy Hacks are small tasks designed to be ideal starting points for new LibreOffice developers, so you can take them on without needing a lot of experience with the project or source code.

The first thing to do is read the quick introduction on this page – it explains the workflow and shows you how to use Bugzilla, which is used to coordinate Easy Hacks. From there, you can choose the language or technology area in which you want to help, eg:

For a full list of Easy Hacks in different languages, see this page, and once you’ve completed a few, you may want to move on to Core Hacks.

So good luck on your coding adventure, we look forward to your contributions, and just let us know on IRC or the mailing list if you have any questions!

Community Week: Development – people, stats and tools

LibreOffice Community Weeks

Earlier in the week we talked to Jan Iversen who is mentoring new contributors to the development team. Let’s now look at some of the people involved, statistics from recent months, and the tools used by developers in their daily work.

Who’s who

As with other large free and open source software projects, LibreOffice developers come from a variety of backgrounds: some are paid to work on the code by companies that use or offer support for LibreOffice; others contribute in their spare time because they enjoy programming and working with the community. If you’ve looking to build a career as a software developer, working on a well-known open source project can provide you with great experience, and is something to put on your CV.

Because the LibreOffice codebase is quite large, most developers focus on certain areas. Some work on specific components of the suite like Calc or Writer, whereas others concentrate on the user interface or improving overall performance. Here is a list of “friendly experts” who are well versed in the code in specific areas, and who can help with questions or problems. But please remember: these are very busy people, who do not always have time to answer beginners’ questions, especially on IRC. The best practice is to send an email to our dev list, which will be seen by all developers including Jan.

Running the numbers

So who is committing code, and how often? Here’s a break-down of commits in the past 12 months:

Some other interesting statistics:

  • In the last 12 months, 282 different contributors had patches merged
  • There are 253 Easy Hacks ready for contributors (new and existing)
  • The Engineering Steering Committee (aka ESC) publishes a list of top 5 contributors every week on our dev mailing list – a lot of companies look at these emails, so being on that list is a plus if you’re searching for a job
  • Development mentor Jan does 50 reviews per week for patches from contributors

Finding the right tools

As mentioned, most of LibreOffice’s source code is C++. Developers use their own choice of editors and development environments to work on the code. The version control system used by LibreOffice developers is Git, while Gerrit is used for review.

For a list of all the tools available to developers, see devcentral.libreoffice.org. Some of the most notable include:

  • Opengrok, which provides a friendly and attractive way to browse the source code
  • Jenkins, which provides CI (continuous integration): every patch which is submitted is built and tested automatically before being merged into the master code branch, to keep master stable
  • Tinderbox, which supports a lot of different setups, and tests regularly (several times a day) that master can build in this special version
  • And Gerrit, where patches end up. This is the system where we review patches before merging to master

So now you have an overview of the development community and the tools that they use – stay tuned for Friday’s post, where we show you how to get involved with Easy Hacks!