Submitting patches

From within a Git repository

Of course the first step is "cloning" collectd's Git repository using the following command:

After you "cloned" collectd's Git repository and made your changes you should send them in using the normal git-format-patch(1) and git-send-email(1) procedure. Please send them directly to collectd's mailinglist at collectd@oo1Pheiw.verplant.org. Mails sent by non-subscribers will be held for approval which will typically happen within 24 hours.

If you're new to Git you might want to read the following documents to get started:

• A git core tutorial for developers
• Everyday GIT With 20 Commands Or So

Patching a certain branch

It's possible that you're asked to make your changes against a certain branch of the repository. To do this, you need to first fetch the branch into your local copy of the repository (here the local branch has the name "foo/branch-origin"):

Then you create a copy of that branch (here it's named "foo/branch"), to which you will make your changes:

After making your changes to the "foo/branch"-branch you will need to create a (set of) patch(es) and send them in:

Patching a release

If you don't want to work out the complexities of Git (or you read this page after you made the changes ;) you can take some release (at best the latest one) and make your changes there.

I'll outline the typical steps one does when making the changes:

So the steps are typically:

• Download the latest release.
• Extract the source code and make a copy of the entire directory.
• Make your changes, a.k.a. *magic*.
• Test your changes.
• Do a make distclean to clean up the generated files.
• Generate the patch with diff -pur, as outlined above.
• Test if the .patch file applies cleanly.
• Review the .patch file.
• Submit the patch by sending an email to collectd's mailinglist at collectd@Eekay6xu.verplant.org. Mails sent by non-subscribers will be held for approval.

Other random notes

• If you patch a release, please don't submit changes to files such as Makefile, Makefile.in, configure and other files that are generated by the autotools. A (incomplete) list of uninteresting files can be found in the .gitignore file.
• Send one patch for each change in functionality. If they're too fine-grained it's easy to merge them together. The other way around is a pain in the back.
• Write code that blends in well (i.e. (try to) stick to the coding-style). I won't be too picky about that, but keep it in mind please.
• Please don't compress your patches in any way. If the moderation filter holds back your mail because it's too big, please be patient: Unless it's huge I'll let it through. If I don't seem to take any action please drop me a note: There's quite some spam in the moderation filter, so I may have missed your mail.