About | News | Status | Get | FAQs | Documentation | Bugs | MailingLists | Contributing
Repositories
|
The repositories contain the skeleton code only, this means you need to run bootstrap.sh after you have cloned the repository, see the README file for additional instructions and notes |
|
cclive-np.git holds misc. files related to the cclive project, including this website |
Branches
The repository contains the maint, the maint-0.7, the next and the master branches.
maint |
Reserved for the maintenance releases |
maint-0.7 |
For the maintenance releases of 0.7 |
master |
Holds the last release, this branch is considered to be stable — it gets updated only when the next branch graduates (merged into master) |
next |
The code currently being developed for the next release |
Patches
Guidelines: Code of conduct
- Confirm against the current code
-
Make sure your patches apply against the current project git repository code. The developers follow the git repository code changes in the next branch.
- Post early, listen to feedback
-
Post your patches (to cclive-devel list) early and listen to the feedback. Never assume that your patch gets automatically committed after posting it. If you wish to have your patch committed, then commit to the discussion.
If your patch has not received any feedback after the initial post:
-
It may have been committed to the repo already (check to confirm)
-
No one has taken a look at it yet (be patient)
-
You didn’t read this page thoroughly (read again)
-
The mail got lost (check the archives)
-
- Major changes
-
Discuss any major changes on the cclive-devel mailing list, first.
- Update
-
Update tests and/or documentation, particularly if you are adding a new feature or changing the output of a program.
- Sign-off
- Indent
-
Indent your code to the requirements.
- Guide
-
See also Richard Jones' guide on how to get your code into an open source project.
Recommendations
- Use git(1)
-
Don’t be square.
- Use git-send-email(1)
-
Felipe Contreras has written a guide on how to use this command effectively.
- Split large changes
-
Split large changes into series of smaller patches (self-contained if possible). Include an explanation of each patch and how the sequence of patches fits together.
- Describe changes
-
In each commit message, describe all of the changes you are making, the subject line describes only one. Write good git commit messages, for example:
Header line: explaining the commit in one line Body of the commit message, which is a few lines of text explaining the changes in details, possibly giving some background about the issue being fixed, etc. The body of the commit message can be >1 paragraphs, and please use proper word-wrap, keeping columns shorter than 74 characters. This way "git log" will show everything nicely even when it is intended. Reported-by: Whoever-reported-it Signed-off-by: Name <email>
Sign-off your patches
Please either send signed-off patches or a pull request with signed-off commits. This means adding a line that says:
Signed-off-by: Name <email>
at the end of each commit message, indicating that you wrote the code and have the right to pass it on as a Free Software patch. For example, with git-commit(1) you would normally use the -s switch.
|
|
2013-05-23: The project will no longer accept patches that have not been "signed-off" |
Alternative methods of posting
- Pull requests
-
Pull requests are OK, although patches are preferred. You can post the requests to the cclive-devel mailing list.
Formatting conventions
We have strict code-formatting conventions, particularly, with the new code.
-
Keep lines under 80 characters (72 is preferred)
-
Use spaces, not tabs for indenting
C source code
You can use astyle(1) for reformatting:
$ astyle --style=gnu -c --indent=spaces=2 foo.cpp
Code indentation conventions
Number of spaces for each indentation level is 2.
|
|
The source code must not contain any tab characters |
Other conventions
- vim (modeline)
-
Each source code file .{cpp,h} in the cclive project must end to line:
// vim: set ts=2 sw=2 tw=72 expandtab: