2013-07-24 15:33:48 -04:00
|
|
|
How to Contribute Patches to FreeSWITCH
|
|
|
|
=======================================
|
|
|
|
|
|
|
|
Download the Source Code
|
|
|
|
------------------------
|
|
|
|
|
2014-12-24 11:37:34 -05:00
|
|
|
git clone https://freeswitch.org/stash/scm/fs/freeswitch.git
|
2013-07-24 15:33:48 -04:00
|
|
|
cd freeswitch
|
|
|
|
|
2014-09-12 13:42:05 -04:00
|
|
|
Ensure Git is Setup
|
|
|
|
-------------------
|
|
|
|
|
|
|
|
# tell git your full name and email address; make sure to use your
|
|
|
|
# real name and not a username
|
|
|
|
./scripts/setup-git.sh
|
|
|
|
|
2014-09-18 17:42:44 -04:00
|
|
|
Create Your Commits
|
|
|
|
-------------------
|
2013-07-24 15:33:48 -04:00
|
|
|
|
|
|
|
# create a topic/feature branch in your local repository
|
|
|
|
git checkout -b myfeature
|
|
|
|
|
|
|
|
# make your change
|
|
|
|
emacs .
|
|
|
|
|
|
|
|
# commit the results locally; see below for how to write a good
|
|
|
|
# commit message
|
|
|
|
git commit -va
|
|
|
|
|
|
|
|
# create more commits as needed such that each commit represents a
|
|
|
|
# logically separate change
|
|
|
|
#while true; do emacs .; git commit -va; done
|
|
|
|
|
2014-09-12 13:42:05 -04:00
|
|
|
# review changes; ensure your author name is correct
|
|
|
|
git log -p
|
|
|
|
|
2014-09-18 17:42:44 -04:00
|
|
|
Create a Pull Request
|
|
|
|
---------------------
|
2013-07-24 15:33:48 -04:00
|
|
|
|
|
|
|
# navigate to the FreeSWITCH JIRA
|
2014-12-24 11:37:34 -05:00
|
|
|
chromium https://freeswitch.org/jira
|
2013-07-24 15:33:48 -04:00
|
|
|
|
2014-09-18 17:42:44 -04:00
|
|
|
# create an account in JIRA and create a new issue
|
|
|
|
|
|
|
|
# navigate to FreeSWITCH Stash
|
2014-12-24 11:37:34 -05:00
|
|
|
chromium https://freeswitch.org/stash
|
2014-09-18 17:42:44 -04:00
|
|
|
|
2014-12-27 21:49:55 -05:00
|
|
|
# Using the same credentials as Jira, login to Stash; create a forked FS repository; read
|
2014-09-18 17:42:44 -04:00
|
|
|
# the details here:
|
2014-12-24 11:37:34 -05:00
|
|
|
chromium https://freeswitch.org/confluence/display/FREESWITCH/Pull+Requests
|
2014-09-18 17:42:44 -04:00
|
|
|
|
|
|
|
# add your repository as a remote (change to your username)
|
|
|
|
git remote add stash ssh://git@stash.freeswitch.org:7999/~johndoe/freeswitch.git
|
|
|
|
|
|
|
|
# push your changes to a branch
|
|
|
|
git push stash +HEAD:myfeature
|
|
|
|
|
|
|
|
# create a pull request as described here:
|
2014-12-24 11:37:34 -05:00
|
|
|
chromium https://freeswitch.org/confluence/display/FREESWITCH/Pull+Requests
|
2013-07-24 15:33:48 -04:00
|
|
|
|
2014-09-18 14:34:36 -04:00
|
|
|
Guidelines for a Good Commit
|
|
|
|
----------------------------
|
|
|
|
|
|
|
|
To the extent possible and appropriate, address only one issue per
|
|
|
|
commit. When we review your commit, anything that doesn't need to be
|
|
|
|
there will only create confusion.
|
|
|
|
|
|
|
|
This means that, for example, unrelated refactoring or whitespace
|
|
|
|
cleanups should generally happen in separate commits. Whitespace
|
|
|
|
cleanup commits should not change anything other than whitespace, and
|
|
|
|
refactoring commits should strive to preserve identical behavior.
|
|
|
|
|
|
|
|
However, don't go overboard. A commit should do some identifiable
|
|
|
|
thing completely. If you're adding a new module, the build changes
|
|
|
|
for that module should go in the commit that adds the module itself.
|
|
|
|
If you're adding a feature, the feature should work after applying
|
|
|
|
that commit.
|
|
|
|
|
|
|
|
We don't need to see your missteps and corrections. Use `git rebase
|
|
|
|
-i` to squash those out of your history before submitting the commit
|
|
|
|
series to us. It should look like you got everything right the first
|
|
|
|
time.
|
|
|
|
|
|
|
|
Use `git log -p` to verify that each diff is correct and minimal, and
|
|
|
|
that your git author name is correct and complete.
|
|
|
|
|
2013-07-24 15:33:48 -04:00
|
|
|
Writing a Good Commit Message
|
|
|
|
-----------------------------
|
|
|
|
|
|
|
|
Your commit message consists of two parts: the subject and the body.
|
|
|
|
|
|
|
|
The subject is like the subject in an email message. It should be
|
|
|
|
short -- typically less than 50 characters -- and it should concisely
|
|
|
|
describe the purpose or effect of your change.
|
|
|
|
|
|
|
|
If you're having a difficult time writing a short subject for your
|
|
|
|
commit, perhaps your commit should be broken into smaller separate
|
|
|
|
commits.
|
|
|
|
|
|
|
|
The commit body can be longer and can consist of multiple paragraphs.
|
2014-08-21 16:37:08 -04:00
|
|
|
The text of the body should be hard wrapped to 68-72 characters. (In
|
|
|
|
Emacs you can hard wrap text with `M-q`.)
|
2013-07-24 15:33:48 -04:00
|
|
|
|
|
|
|
When writing the commit body, describe in detail the problem that your
|
|
|
|
commit aims to solve, how your commit solves the problem, and any
|
|
|
|
changes in behavior that result from your change, such as new
|
|
|
|
variables, command flags, or breaks in backward compatibility.
|
|
|
|
|
|
|
|
Your commit message should be written in the present tense in
|
|
|
|
imperative style. Your message should talk about what the patch
|
|
|
|
*does*, not what you *did* to write it.
|
|
|
|
|
|
|
|
The commit subject is the first line of your commit message, then
|
|
|
|
there is an empty line, then your commit body starts. A good commit
|
|
|
|
message might look like this:
|
|
|
|
|
2014-09-18 17:10:18 -04:00
|
|
|
commit b5c64234ea5d4417abe02b282d6f41c019f2252f
|
|
|
|
Author: John Doe <johndoe@example.com>
|
|
|
|
Date: Tue Jan 19 03:14:07 2014 +0000
|
|
|
|
|
2014-09-18 17:08:14 -04:00
|
|
|
Add frobinator support to mod_sofia
|
|
|
|
|
|
|
|
Without proper frobinator support users had to make multiple calls
|
|
|
|
to shell scripts to do the sort of frobbing needed in high call
|
|
|
|
volume environments.
|
|
|
|
|
|
|
|
With this change, we now link to libfrob and support the IETF
|
|
|
|
draft-cross-voip-frobbing API.
|
|
|
|
|
|
|
|
After appropriate amounts of frobbing have been done, a new variable
|
|
|
|
`frobbing_done` is set in the caller's channel.
|
|
|
|
|
|
|
|
FS-XXXX #resolve
|
2013-07-24 15:33:48 -04:00
|
|
|
|
2013-08-02 10:37:54 -04:00
|
|
|
Patches Related to JIRA Issues
|
2013-08-02 04:23:38 -04:00
|
|
|
------------------------------
|
|
|
|
|
2013-08-02 10:37:54 -04:00
|
|
|
When your patch is related to an issue logged in JIRA, add the
|
|
|
|
identifier for the issue (e.g. FS-XXXX) to the body of your commit
|
|
|
|
message at the beginning of a line, typically the last line or just
|
|
|
|
before "Signed-off-by:" and "Thanks-to:" lines. This helps our JIRA
|
|
|
|
bot do useful things by relating the commit to the issue.
|
2013-08-02 04:23:38 -04:00
|
|
|
|
2013-08-02 10:37:54 -04:00
|
|
|
If you believe your patch resolves the issue in question, follow the
|
2014-09-18 15:50:25 -04:00
|
|
|
issue number with a space and the "#resolve" directive as in the
|
2013-08-02 10:37:54 -04:00
|
|
|
example above.
|
2013-08-02 04:23:38 -04:00
|
|
|
|
2014-09-18 16:02:19 -04:00
|
|
|
Avoid Merges
|
|
|
|
------------
|
|
|
|
|
|
|
|
When you've created a local git branch to make and test your changes,
|
|
|
|
it can be tempting to merge that branch periodically against our git
|
|
|
|
HEAD, particularly if the branch lingers for some time. Don't do
|
|
|
|
this. Instead, please rebase your branch onto our tree before
|
|
|
|
submitting the commits to us. Random "update branch to master" merges
|
|
|
|
make our history hard to understand and make it more difficult to
|
|
|
|
isolate regressions with `git-bisect`.
|
|
|
|
|
2014-09-19 00:29:34 -04:00
|
|
|
New Module Checklist
|
|
|
|
--------------------
|
|
|
|
|
|
|
|
When proposing a new module:
|
|
|
|
|
|
|
|
* Add a `Makefile.am` for the module
|
|
|
|
* Add the module to the FS `configure.ac`
|
|
|
|
* Add the module to `build/modules.conf.in` (commented out)
|
|
|
|
* Describe the module in as much detail as possible in the comments
|
|
|
|
at the top of the module
|
|
|
|
* Add our whitespace footer to the module files; ensure the \*.[ch]
|
|
|
|
module files use tabs for indentation and are free of trailing
|
|
|
|
whitespace (e.g. in Emacs, run `M-x whitespace-mode`, then `M-x
|
|
|
|
whitespace-cleanup`)
|
|
|
|
* Remove any unused code left over from debugging
|
|
|
|
* Ensure symbols not meant to be exported are declared `static`
|
|
|
|
* Don't add any files to `conf/vanilla`
|
|
|
|
* Write a commit message body describing the module, why it's useful,
|
|
|
|
what it does, how it works, and any parts not yet implemented
|
|
|
|
|
2014-09-18 15:47:36 -04:00
|
|
|
Do As We Say...
|
|
|
|
---------------
|
|
|
|
|
|
|
|
When you look in our git history, you'll find not all commits follow
|
|
|
|
the guidelines here. Don't be fooled by this. These guidelines are
|
|
|
|
what we want, and your commits should follow them.
|
|
|
|
|
|
|
|
It's always difficult to counsel, "do as we say and not as we do," but
|
|
|
|
the truth is that the format of your commits will be held to a
|
|
|
|
different standard than the commits of people who have written the
|
|
|
|
majority of the code in FS. For one thing, your commits will be
|
|
|
|
reviewed, so following a careful format helps us to review and merge
|
|
|
|
your patches quickly and efficiently.
|
|
|
|
|
|
|
|
We want a clean and sensible git history, and over time more
|
|
|
|
contributors will be following the guidelines here.
|
|
|
|
|
2013-07-24 15:33:48 -04:00
|
|
|
Where to Go for Help
|
|
|
|
--------------------
|
|
|
|
|
|
|
|
If you have any questions or run into any roadblocks please reach out
|
|
|
|
to us. You can send an email to our development mailing list:
|
|
|
|
|
|
|
|
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
|
|
|
|
|
|
|
|
Note that while you're free to send a patch to that list for questions
|
|
|
|
or for review, patches sent to the mailing list will not be considered
|
|
|
|
for inclusion. Patches that you want included in FreeSWITCH must be
|
|
|
|
submitted to JIRA.
|
|
|
|
|
|
|
|
You can also reach us on freenode.net at:
|
|
|
|
|
2014-09-18 17:14:52 -04:00
|
|
|
> \#freeswitch-dev
|
2013-12-10 13:19:36 -05:00
|
|
|
|
2013-07-24 15:33:48 -04:00
|
|
|
Finally, feel free to join us in our weekly conference call. Many of
|
|
|
|
the core developers are often on the call and you'll have an
|
|
|
|
opportunity at the beginning or end of the call to ask your questions:
|
|
|
|
|
2014-12-27 21:49:55 -05:00
|
|
|
> https://freeswitch.org/confluence/display/FREESWITCH/ClueCon+Weekly+Conference+call
|