[ << Introduction to contributing ]	[Top][Contents][Index][ ? ]			[ Quick start >> ]
[ < Overview of work flow ]		[  Up : Introduction to contributing ]	[ Mentors > ]

1.3 Summary for experienced developers

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

• source repository: hosted by GNU savannah.

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

• issue tracker: currently hosted by Sourceforge.

  https://sourceforge.net/p/testlilyissues/issues/
  

• patch review: Reitveld – the collaborative code review tool.

  https://codereview.appspot.com
  

• environment variables: many maintenance scripts, and many instructions in this guide rely on predefined Environment variables.
• mailing lists: given on Contact.
• Git branches:
  • master: always base your work from this branch, but never push directly to it. Patches are always pushed directly to the staging branch instead.
  • staging: always push to this branch after a successful patch review cycle (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. upload it with our custom git-cl ‘helper-script’; see git-cl. In addition to uploading patches to the Google’s Rietveld code review tool the script will also update the issue tracker (or add a new issue as appropriate) so that any reference to the patch is not lost. The current “status” of any patch submitted is always managed on the issue tracker; also see Issues.

     Once submitted the patch will be given a status of Patch-new and will enter the “Patch Countdown”. 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, make doc and a make test-baseline/check –, 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 the issue tracker and the Rietveld code review tool for the submitted patch, 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 issue tracker (not the Rietveld code review tool) 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 issue tracker is updated, and the developer can now push it directly to the staging branch (or email the patch – created with git format-patch command – to one of the other developers who can push it for you).
  5. Automatic scripts run every few hours to merge the staging branch with master.

  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.

---

[ << Introduction to contributing ]	[Top][Contents][Index][ ? ]			[ Quick start >> ]
[ < Overview of work flow ]		[  Up : Introduction to contributing ]	[ Mentors > ]

<< Back to Documentation Index

LilyPond — Contributor’s Guide v2.21.0 (development-branch).