[ << 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
- environment variables: many maintenance scripts, and many instructions in this guide rely on predefined Environment variables.
- mailing lists: given on Contact.
- branches:
-
master
: base your work from this, but do not push to it. -
staging
: after a successful review (see below), push here. -
translation
: translators should base their work from this, and also push to it. -
dev/foo
: feel free to push any new branch name underdev/
.
-
- regression tests:
also known as “regtests”; this is a collection of more than a
thousand .ly files. We track the output of those files between
versions.
If a patch introduces any unintentional changes to the regtests, we will likely reject it – make sure that you are aware and can explain any regtest changes. More info in Regression tests.
- reviews:
after finishing work on a patch or branch:
-
upload it with our custom
git-cl
. In addition to uploading it to the google rietveld code review tool, this adds a tracker issue so that we don’t lose your patch. The “status” of your patch is kept on the issue tracker; see Issues.https://github.com/gperciva/git-cl
Your patch will be given
Patch-new
status. More info in Uploading a patch for review. -
If your patch passes some automatic tests, it will be given
Patch-review
status. This generally happens within 24 hours. -
After that, the patch must wait for the next “patch countdown”,
which occur 3 times a week. If there are a lot of patches waiting
for a countdown, a subset of patches are chosen randomly. When
your patch is put on a countdown, it will be given
Patch-countdown
status. -
The countdown is a 48-hour period which gives other developers one
last chance to review the patch. If no significant problems are
found, your patch will be given
Patch-push
status. -
You may now either push it to the
staging
branch, or email your patch (created withgit format-patch
) to somebody who will push it for you.
Advanced note: Yes, this process means that most patches wait between 60-120 hours before reaching
master
. This is unfortunate, but given our limited resources for reviewing patches and a history of unintended breakage inmaster
, this is the best compromise we have found. -
upload it with our custom
[ << Introduction to contributing ] | [Top][Contents][Index][ ? ] | [ Quick start >> ] | ||
[ < Overview of work flow ] | [ Up : Introduction to contributing ] | [ Mentors > ] |