[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

Gerrit User Summit 2018, Palo Alto, CA

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.

Gerrit User Summit 2016, Mountain View, CA

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.

Gerrit Hackathon at SAP, Walldorf

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”:

label:Code-Review+2,owner

Suggest changes for auto merge: approval by change owner + verify by the bot (assuming default label set: CRVW + VRFY):

project:foo
branch:master
is:open
is:mergeable
label:Code-Review+2,owner
label:Verified+1,buildbot
NOT label:Code-Review-2
NOT label:Verified-1

Adding OAuth authentication scheme for Gerrit

I gave a talk on last FOSDEM about Gerrit User Authentication. Here are the slides. It was a long and interesting journey to add OAuth authentication scheme support in Gerrit Code Review. Luca spent a lot of time trying to get GitHub OAuth support in Gerrit core. After almost 1 year work on this change and countless reviews and addressed comments (57 patch set) it was abandoned. But the work wasn’t in vane. The lessons learned from this attempt was:

  • There must be support for multiple authentication providers
  • Because of the nature of the OAuth providers, the support cannot be done in Gerrit core, and must be done as a plugin
  • To write a plugin extension point must be exposed first

However, in the past there were quite some attempts to implement generic pluggable auth scheme extension point, but they all were abandoned. So it was more or less clear if we would revamp the attempt to introduce something totally generic it would require a lot of efforts and would take another couple of years of work. Instead we should try to add KISS extension point, just for OAuth. Sure, some folks in the wild were disappointed, because they would prefer to see a big generic pluggable auth extension point in Gerrit, but we just wanted to get the job done for this specific use case.

Another thing to solve, after the extension point was extracted and plugin support for the following OAuth providers Google, GitHub, CAS and BitBucket was introduced, was OpenID providers. That why I also added Hybrid OAuth+OpenID auth scheme support.

I would like to thank Norbert Thiebaud from The Document Foundation for invaluable help in many discussions we had during my work on Hybrid OAuth+OpenID authentication.

Gerrit User Summit/Conference in Mountain View, CA

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.

Upgrading OpenSuSE to 13.1

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 
GRUB_DISTRIBUTOR="openSUSE 13.1"
#run
grub2-mkconfig -o /boot/grub2/grub.cfg

Gerrit Code Review 2.8 is released

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.

Main reason to use open source software: customizability

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:

  • Freedom
  • Quality
  • Security
  • Try it first
  • Community

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:

$>git

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:

ban-commit
create-account
[...]

gbildify expat module and test it on windows

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:

.IF "$(BUILD_X64)"!=""
# ---------------- X64 stuff special ---------------------
#  use UNICODE only because shell/shlxthandler
#  doesn't link against ascii_expat_xmlparse
#---------------------------------------------------------
SLOFILES_X64=$(SLO_X64)/xmlparse.obj \
$(SLO_X64)/xmlrole.obj \
$(SLO_X64)/xmltok.obj
CDEFS_X64+=-DXML_UNICODE -DCOMPILED_FROM_DSP
CFLAGS_X64+=-I..
LIB1TARGET_X64=$(SLB_X64)/$(TARGET)_xmlparse.lib
LIB1OBJFILES_X64=$(SLO_X64)/xmlparse.obj
LIB2TARGET_X64=$(SLB_X64)/$(TARGET)_xmltok.lib
LIB2OBJFILES_X64=$(SLO_X64)/xmlrole.obj \
$(SLO_X64)/xmltok.obj
.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.

LibreOffice: new mork driver

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:

  1. what has an office suite to do with a browser?
  2. why it is enabled per default, if it’s something optional?
  3. why it was failing to compile on my recent Ubuntu box?

Six months later i knew the answers to all these questions 😉

  1. it is needed for Thunderbird address book integration and some other extensions.
  2. 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.
  3. 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.