As you may know, I was participating in this year Gerrit User Summit, 15th-16th November 2018 in Palo Alto, CA.
I gave two talks: Bazel build gerrit: New and Noteworthy about optimizing Gerrit Build with Bazel and Gerrit Change Workflows with details about interesting multi stop journey that replaced somewhat confusing Draft change/Draft patchset workflows with streamlined Work-In-Progress workflow.
There were plenty of great talks, including Gerrit Analytics, Kubernetes, Multi-Site and Mulit-Master deployments and details about new and shiny Gerrit 3.0 that is going to be tentatively released in Q2 2019.
During the developer hackathon, that took place before the user conference, Gerrit 2.16 release was conducted. Major new feature is: new UI has reached parity with the old GWT UI and therefore old GWT UI is deprecated in 2.16 and in fact was already removed on master and will not be included any more in Gerrit 3.0. Another major feature is Git protocol version 2.0 is fully supported through HTTP and SSH layers.
This release also included small improvements, like simplified debugging capability for UI, SSH and GIT requests. Moreover, submit rules can now be written in Java language as a Gerrit plugin, in addition to Prolog rules.
I would like to thank GerritForge Ltd. for sponsoring travel cost for my participation.
2018 has been a very special year – we were celebrating the 10th anniversary of Gerrit, on 14th November, 2018. 10 years ago Shawn Pierce created a first commit in Gerrit repository. It is such a terrible loss for the whole open source community in general and for Gerrit ecosystem in particular that long-time Git contributor and founder of the Gerrit Code Review project, passed away in January this year.
As you may know i was participating in this year Gerrit User Summit, 12th-13th November 2016, followed by Developer Hackathon in Mountain View, CA.
There were plenty of great talks, including EMail ingestion, Atomicity with change-sets, Gerrit analytics, Update on new and shiny UI, called PolyGerrit, based on Google’s own Polymer project, Zero-downtime Gerrit upgrades and what’s new and in Gerrit 2.12, 2.13 and coming next 2.14 releases.
I gave a talk about the status of my work on implementation of Bazel build for Gerrit.
After the user conference we had couple of days of Gerrit developer hackathon, where I continued to work on Bazel build implementation for Gerrit, approaching the feature parity with Buck build implementation. During the hackathon I uploaded a CL for removing Buck build, so that the new Gerrit version is going to be built and released with Bazel only.
I would like to thank Frobese GmbH company for sponsoring travel cost for my participation.
In September 2016, I attended 5 days Gerrit developer hackathon, in Walldorf, SAP.
As always it was a big pleasure to meet SAP Git/Gerrit hackers in person:
Sasa, Matthias, Michael and Chris.
I finalized my work on extending labels in secondary index to be change owner votes aware. Now it’s possible to use these gerrit queries:
Skip WIP changes, rejected by change owner:
is:open NOT label:Code-Review-2,owner
Skip non reviewable changes, approval by change owner:
is:open NOT label:Code-Review+2,owner
Detect changes, that violates “non-self approval policy”:
Suggest changes for auto merge: approval by change owner + verify by the bot (assuming default label set: CRVW + VRFY):
Continue reading Gerrit Hackathon at SAP, Walldorf
As you may know i was participating in this year Gerrit User Summit, 21-26 March, followed by Developer Hackathon in Mountain View, CA.
I had three presentations: Gerrit@LibreOffice with detailed explanation of Gerrit Buildbot plugin and two feature requests:
Among other presentations Edwin summarized new features in upcoming Gerrit 2.9 release, that was later converted to regular documentation page in Gerrit. Shawn presented plans for future Gerrit/Git development:
- Moving from database to Git to store meta data
- Provide alternative Git storage backend(s) to file system backend.
- Improving Git submodule feature set
During the Hackathon i continued the work on inline edit feature: to allow to change code during review directly in browser. It should also have support to create a new empty isolated change and a follow-up change from a given change directly in browser and allow to populate it with code changes.
On Sunday we had mountain bike tour in Santa Cruz national park. Thanks Edwin for these great pictures:
Big thank to The Document Foundation for funding my participation.
OpenSuSE 13.1 was released on November 2013, so i am late to upgrade my W530 Laptop. The main reason to upgrade is to make Intel’s on board card and NVIDIA’s card work in Optimus Modus. For that the latest kernel version is required.
Following these straight forward instructions to upgrade the distribution from the command line i succeeded to screw it up: i was unable to login with X and had to switch to console/root mode to recover.
The reason for that was NVIDIA native driver, that wasn’t properly updated with new kernel (probably because repository was deactivated). So i think the step to remove it prior to upgrade should be mentioned in instructions.
After removing all NVIDIA drivers and running `mkinitrd` everything was working again. Well almost.
The grub entry on boot screen still shows 12.3 even though it is 13.1, as splash screen image shows:
It turns out it is long standing bug in OpenSUSE. And it is annoying to have to fix it manually:
#replace this line in /etc/default/grub
grub2-mkconfig -o /boot/grub2/grub.cfg
Last week Gerrit Code Review version 2.8 GA was released. It is a major release and devs have spent 8 months and two Hackathons in London and Boulder to release it. The highlights are:
- Secondary index support
- New change screen
- New plugin API
While each of this features can fill out the whole release for itself, all three combined explain why Gerrit users, developers and early adopters are so excited about the availability of Gerrit 2.8 GA.
Continue reading Gerrit Code Review 2.8 is released
Why are we using open source software? Well that’s a rhetoric question and i am sure you come up with many reasons for that, just to name few:
- Try it first
And many others. How about customizability? Have you already realized that some feature is missing in product “foo”? Fine, what now? Well try to bring the vendor to extend it. But wait, we are using open source software, right? Let’s patch it then 😉 Let’s see how easy it is … but the problem first:
usage: git [--version] [--exec-path[= ]] ...
The most commonly used git commands are:
add Add file contents to the index
branch List, create, or delete branches
clone Clone a repository into a new directory
So now let’s compare that output with our another favorite tool that we all so love: Gerrit:
$>ssh gerrit gerrit --help
gerrit COMMAND [ARG ...] [--] [--help (-h)]
Available commands of gerrit are:
Continue reading Main reason to use open source software: customizability
During my work on migration from dmake to gnu make (gbuildification) of expat module i discovered some innocent looking lines in the old dmake based make file:
# ---------------- X64 stuff special ---------------------
# use UNICODE only because shell/shlxthandler
# doesn't link against ascii_expat_xmlparse
.ENDIF # "$(BUILD_X64)"!=""
So what is BUILD_X64 here and when it is used? My understanding was, that LO isn’t shipping as 64 bit binary on Windows. Tor did some great work on it but it is still highly experimented. So what is all that stuff about? It turns out, that LO does shipp nativ 64 bit extension for 64 bit OS for shell integration and special version of expat (64 bit) must be created for that.
Not big deal, right? So what’s the problem with that? The problem was to test it. Gbuildification has already broken almoust everything, so before merging the gbuildified expat to master some real tests should be done, especially if some native bits are involved. Having only access to WinXP (32 bit) and VS 2008 Express was clearly not sufficient. So before installing a whole blown testbed with new VM, 2008 Server 64 bit, SDKs and 64 bit VS compiler i thought i would just ask the folks out there for help.
Continue reading gbildify expat module and test it on windows
Some history first
First time i compiled LibreOffice (LO) in march 2012, it failed to compile in the seamonkey (moz) module (i didn’t enable it explicitly). I had many questions about moz integration in LO:
- what has an office suite to do with a browser?
- why it is enabled per default, if it’s something optional?
- why it was failing to compile on my recent Ubuntu box?
Six months later i knew the answers to all these questions 😉
- it is needed for Thunderbird address book integration and some other extensions.
- it is (well was) not really optional: mail merge is an important feature, because sooner or later you want to send mails from your office suite to the recipients from your address book. To import the Mozilla Address Book (MAB) data, which is stored in mork file format, LO need some means to read and interpret that format. Because of lack of alternative implementations Mozilla itself was used for that purpose.
- well here things started to become complicated. It was subtle linking issue: compiler tool chain configuration was changed on Debian/Ubuntu: “as-needed” became the default, breaking many tools and libraries, among other the moz module in LO. But why two distros had a compilation problem in the moz module and nobody noticed? Debian/Ubuntu maintainers disabled this “a strangely hacked up Mozilla binary” inside of LO.
Continue reading LibreOffice: new mork driver
As you may know, LibreOffice undergoes currently migration to code review system gerrit. In his post to dev ML Why Gerrit and other consideration Norbert Thiebaud explained the objectives which the initiators of that move are trying to achieve. As though by chance, the first reason behind that move was cit.
a/ Allow dev to pre-build commit on a variety of platform _before_
pushing them to master. iow check and push rather than the current
push and fix. [...]
To see how gerrit fits in current LibreOffice CI picture or what should be done for it let us first take a look at the situation prior to gerrit migration. At the moment there are 23 Tinderboxes (TB), that independently running on donated machines and asynchronously verify different git branches. They upload the build results to the master TB per mail. Master TB extracts the log from the mail and puts it to the web site for that specific branch, i.e. for master you can find it here. Continue reading How Gerrit fits in LibreOffice CI Infrastructure