Coding Guidelines

If you are submitting code, please have a look at the Coding Guidelines page. Please keep some things in mind when preparing your patches for submission:

• use one patch per logical change
• test all coding changes
• If it is a change to the build system, make sure that the test/buildtest.sh script still works.
• include some commentary above your patch in your email
• when mailing patches, try to keep one patch per email
• do not cut and paste patches... either read them in directly to your mail body (preferred), or send as an attachment
• add a [PATCH] prefix to your subject line

Generating Patches

Generating patches depends on the method you used to get the source code.

• If you are using a tarball, expand the tarball once into a pristine directory, and again into your "working directory." When you are finished and ready to patch, do:

  	cd barry-work
  	./buildgen.sh cleanall
  	cd ..
  	diff -ruN barry-orig barry-work > patchfile
  

• If you are using CVS, make your changes in your working directory, and then do:

  	cd barry-cvs
  	./buildgen.sh cleanall
  	cvs diff -u > patchfile
  	grep ^? patchfile
  

  Any new files that you've added to your tree will need to be attached to your patch email, as CVS has no way to add files without write access to the repository.
  
  
  
  
• If you are using the git tree, you can make your changes in your own branch, and then create patches for each commit you've made:

  	cd barry-git
  	git format-patch origin/master
  

Methods for Submitting Patches

Submitting changes can happen in one of three methods:

• Send a patch to the mailing list.
• Publish your own git repository (perhaps on repo.or.cz) and notify the mailing list, indicating the branch you want people to pull from when you're ready.
• Use the "mob" branch on Barry's git repository, and.... send a notification to the mailing list.

Using the Mob Branch

The public git repository service at repo.or.cz provides an interesting feature, which allows anyone to push to a "mob" branch of a repository, if so configured by the admin. It would go something like this:

        # clone with mob user
        git clone git+ssh://mob@repo.or.cz/srv/git/barry.git barry

        cd barry
        git checkout -b mob origin/mob
        git diff origin/master..mob             # make sure master == mob
        <make changes>
        git add ... && git commit
        git push origin mob
        <send email to the list, include the SHA1 sum of the commit>

This is a novel idea, as well as a security risk for anyone who blindly runs whatever is in the mob branch. Hence the recommended diff check above, to make sure you're working on an official branch. The mob user can only push to the mob branch, so all other branches are read-only, and have been reviewed at least once by the project maintainer. But the mob branch frees people up to use git, who may not have their own hosting, or who may not want to bother setting up their own git repo. People can use it to collaborate on a feature as well. Let your imagination run wild. You can read more about the ideas behind the mob branch at the repo.or.cz mob page