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: needed by many maintenance scripts, and many instructions in this guide rely on them; see Environment variables.
• Mailing lists: given in Contact.
• Git branches:
  • master: always base your work on this branch, but never push directly to it.
  • dev/foo: feel free to push any new branches under dev/ and use GitLab to create Merge Requests (MR), which eventually get merged into master after they have passed automatic testing (see below).
• Regression tests: also known as “regtests”. A collection of around two 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) – if you expect any regression test changes, always make sure 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 you should do the following.
  1. Commit the changes and create a Merge Request. See Uploading a patch for review for more information.
  2. A Merge Request is usually automatically tested within an hour 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.