1.3 Summary for experienced developers

If you are already familiar with typical open-source tools, here’s what you need to know:

• ‘official’ source repository: hosted by GNU Savannah

  https://git.savannah.gnu.org/gitweb/?p=lilypond.git

• development platform: hosted by GitLab; also includes the issue tracker (see Issues)

  https://gitlab.com/lilypond/lilypond/

• environment variables: many maintenance scripts, and many instructions in this guide rely on predefined Environment variables.
• mailing lists: given on (web)Contact section ‘Contact’ in General Information.
• Git branches:
  • master: always base your work from this branch, but never push directly to it. Instead, use GitLab to merge changes after they have passed automatic testing (see below).
  • translation: Translators should base their work on this branch only and push any translation patches directly to it as well.
  • dev/foo: feel free to push any new branch name under dev/.
• regression tests: also known as “regtests”. A collection of more than a thousand .ly files that are used to track LilyPond’s engraving output between released stable and unstable versions as well as checked for all patches submitted for testing.

  If a patch introduces any unintentional changes to any of the regtests it is very likely it will be rejected (to be fixed) – always make sure that, if you expect any regression test changes, that they are explained clearly as part of the patch description when submitting for testing. For more information see Regression tests.

• reviews: after finishing work on a patch or branch:
  1. Commit the changes and create a merge request. More information on this can be found in the section Uploading a patch for review.
  2. Patches are generally tested within 24 hours of submission. Once it has passed the basic tests – make check, make, make doc – the tracker will be updated and the patch’s status will change to Patch::review for other developers to examine.
  3. Every third day, the “Patch Meister” will examine all merge requests currently under review, looking for any comments by other developers. Depending on what has been posted, the patch will be either; “moved on” to the next patch status (Patch::countdown); set back to Patch::needs_work; or if more discussion is needed, left at Patch::review. In all cases the merge request will be updated by the Patch Meister accordingly.
  4. Once another three days have passed, any patch that has been given Patch::countdown status will be changed to Patch::push, the merge request is updated, and the developer can now rebase and merge to the master branch (or ask one of the other developers to merge it for you).

  Advanced note: This process does means that most patches will take about a week before finally being merged into master. With the limited resources for reviewing patches available and a history of unintended breakages in the master branch (from patches that have not had time to be reviewed properly), this is the best compromise we have found.

This document was generated by gub on July 13, 2020 using texi2html 1.82.