Development/GerritMigration

TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate

• Wiki Home
• Development
• Design
• QA
• Events
• Documentation
• Website
• Localization
• Accessibility
• Marketing
• Diversity
• Wiki Help

• Overview
• Reporting Bugs
• How to build
• Code Overview
• Git Commands
• Debugging
• EasyHacks
• Release Plan
• FAQ
• Developers
• Extensions
• → Open Issues

The migration to gerrit is finished. This page is kept for historic reference only.

Gerrit Migration

This page is about the migration of Libreoffice development to enable code reviews with Gerrit.

Team

Development: Bjoern Michaelsen

Infrastructure: Robert Einsle, Alexander Werner, Florian Effenberger

Marketing: N.N. (no urgent action items, volunteers welcome still)

Design/UX: N.N. (no urgent action items, volunteers welcome still)

Documentation: N.N. (no urgent action items, volunteers welcome still)

QA: N.N. (no urgent action items, volunteers welcome still)

L10n: no action items expected

Gerrit Documentation

• http://gerrit.googlecode.com/svn/documentation/2.1/install.html
• http://gerrit.googlecode.com/svn/documentation/2.1/project-setup.html

Design Decisions made along the way and their reasons

Hardware specs

We need at least 2-4GB RAM:

• "The git repos (all included) shy of 2GB. We are probably going to use going to use MySQL as back-end for gerrit... which will need decent caching too and of course Java is a hog... but all in all we should be fine with 16GB. I have no clue about Jenkins requirement... but that should still fit." -- Norbert
• "Tried on a one core VM on a C2Q Q9650 with 1GB (host 8GB): Pushing 90a53962420ae84e2c0577683864626d6a67896a..422b71e32bf0881cc643cee76b596f6031511829 (27 commits) took real 0m15.391s with the system going up to ~80% io wait, System has 12MB free and 91MB buffers. Likely having 2GB will already help lot. No slowdown was noticed when only browsing the commits." -- Bjoern
• "I just did a bigger upload on the 2GB virtual machine (2458 changes with review) and that took 2m37.410s and was completely CPU-bound." -- Bjoern

add more here

tbd

Scribble Area

(Wild unfinished thoughts here)

Aggressive default workflow for master

The default workflow for master will be eased by a bot which automatically submits every change to master that:

• is older than 24 hours
• is by a known contributor (i.e. one that has direct commit rights on master)
• has no negative review (either human or tinderbox)

Of course, known contributors are free to still submit to master (before and after the 24 hours) disregarding the above conditions.

Tinderbox coordination

Probably ignore stream-events and score next-best-to-build based on https://lists.freedesktop.org/archives/libreoffice/2012-June/033315.html

Action items

open

phase 1

• setup mail notifications to the developer mailing list (Robert Einsle)
  • see tdf#51159

phase 2

• setup patch drop mailbox (Bjoern Michaelsen, maybe an EasyHack)
  • https://launchpad.net/~r-gerrit-0 email at gerrit@libreoffice.org
• setup automatic patch license check (EasyHack?)
• make gerrit the push-to location for core (Bjoern Michaelsen)
• integrate tinderboxes (Robert Einsle, Bjoern Michaelsen, Norbert Thiebaud(?))

phase 3

• migrate other repositories (N.N.)
• revisit default workflow with lessons learned since phase 1 (Bjoern Michaelsen)
• possible website branding (N.N.)
• Marketing solution once everything works smooth (N.N.)

done

phase 0

• install local instances (Bjoern Michaelsen, Norbert Thiebaud)
• install on VM at http://gerrit-test.libreoffice.org (Bjoern Michaelsen, Norbert Thiebaud) (closed down again, tests finished)
• Test workflows (Bjoern Michaelsen, Norbert Thiebaud)
• idenitify hardware requirements (Bjoern Michaelsen, Norbert Thiebaud)
• Rent and setup a machine (Florian Effenberger)

phase 1

• install and setup Postgres (Robert Einsle)
• work out db-backups solution (Robert Einsle)
• basic audit of "bouncycastle" stuff delivered with gerrit, can we use only openssh instead? Does this work out with gerrits key management? (Bjoern Michaelsen) => just use it, its assume to be safe/reviewed, google uses it
• setup apache as a proxy in front of the gerrit web interface (Robert Einsle)
• Do we need ssl-certs for https/OpenID? (Roebrt Einsle)
• Do we win anything by using Jetty/application containers? (Bjoern Michaelsen) => assuming no for now
• Harden the availability of gerrit, default startup scripts seem a bit shaky (Bjoern Michaelsen) => dropped, seems to work fine now
• import dev-tools repo for starters (Bjoern Michaelsen)
• work out replication to freedesktop (Bjoern Michaelsen) => just syncing from fd.o for now
• identify and setup an "aggressive" default workflow (i.e. one that does not slow down development) (Bjoern Michaelsen) => dropped for now, instead we keep direct access to master for those who had fd.o commit access
• announce invitation for people to create their accounts and upload their keys (Bjoern Michaelsen)
• document how to use gerrit/get started on wiki and update BuildHowto and so on (Bjoern Michaelsen)
  • Development/gerrit
• make gerrit the push-to location for dev-tools (Bjoern Michaelsen) => dropped, too low traffic to be useful, we had enough testing, just switch with the rest.

phase 2

• import core repo (Norbert Thiebauld)

phase 3

• scripting to automagically identify patches on the mailing list (EasyHack?) => dropped, dropbox mail is more robust
• integrate further tests as optional indicators (subsequenttests for example) (EasyHack) => dropped, tread just as a tinderbox scenario
• enable gitweb integration, use freedesktop or run our own instance? (Robert Einsle)
• setup review workflows for release branches (Bjoern Michaelsen) => done, just keep the defaults