So now your feature is complete. You’ve added test cases for it to
the test suite7, you have
ChangeLog entries that describe all the changes8,
you have documented the new feature9,
and everything works great. You’re ready
to submit the changes for review, and with any luck, inclusion into
gawk
.
There are two ways to submit your changes for review.
To do this, simply compare your branch to the branch off which it is based:
$ git checkout feature/python $ git diff master > /tmp/python.diff
Mail the python.diff file to the appropriate mailing list along with a description of what you’ve changed and why.
The patch file will likely contain changes to generated files, such as awkgram.c or Makefile.in. If you are comfortable manually editing the patch file to remove those changes, do so. If not, then send the file as-is and the maintainer will handle it.
To do this, use ‘git format-patch’:
$ git checkout feature/python $ git format-patch
This creates a set of patch files, one per commit that isn’t on the original branch. Mail these patches, either separately, or as a set of attachments, to the appropriate mailing list along with a description of what you’ve changed and why.
Either way you choose to submit your changes, the gawk
maintainer and development team will review your changes and provide feedback.
If you have signed paperwork with the FSF for gawk
and the maintainer
approves your changes, he will apply the patch(es) and commit the changes.
Which list should you send mail to? If you are just starting to
contribute, use bug-gawk@gnu.org. After making enough
contributions, you may be invited to join the private gawk
developers’ mailing list. If you do so, then submit your changes to
that list.
If you make any substantial changes, you will need to assign copyright in those changes to the Free Software Foundation before the maintainer can commit those changes. See Assigning Copyrights to the FSF, for more information.
You did do this, didn’t you?
You remembered this, right?
You wouldn’t neglect this, would you?