Project leader's guide

This guide helps project leaders perform their tasks.

Review pull requests

Thanks to Github's web interface, reviewing a pull request is very simple. These are some steps that MUST always be followed before merging any patches into the w3af project:

1. Review the code via github's web
2. Fetch the code and review it locally

git remote add righettod https://github.com/righettod/w3af.git
git fetch righettod remote_branch_name:new_local_branch_name
git checkout new_local_branch_name

3. Run the unittests

nosetests --config=nose.cfg path/to/tests.py
git branch -d new_local_branch_name

Please note that the username (in this example righettod) and the remote_branch_name are available at the pull request.

Revert pull requests

Cross your fingers and hope you don't have to, ever, use this link.

Fixing pull requests

Sometimes there are pull-requests which require lots of work to cleanup. A good example is when a contributor sends a pull-request which looks like this:

• Commit A: Started to work on feature X
• Commit B: More progress for X
• Commit C: Nothing to do with X that breaks everything
• Commit D: Finished X

This happens when contributors do NOT follow the Contributing 101 documentation.

Since we don't want them to stress a lot around git internals, we usually fix these bugs ourselves using the following strategy:

• Get the contributor code:

git remote add righettod https://github.com/righettod/w3af.git
git fetch righettod remote_branch_name:new_local_branch_name

• Review the changes:

git lg

• Create a new branch:

git branch feature_x
git checkout feature_x

• Cherry-pick the changes we're interested in:

git cherry-pick A
git cherry-pick B
git cherry-pick D

• Unittest
• Push the new feature branch to the repository: Only useful if we want the user to continue to work on this clean branch

git push -u origin feature_x

• Merge the branch into our current development branch

git checkout develop
git merge feature_x

Forks

When you access the w3af homepage in github you see a very nice icon on the top-right corner with the number of forks the project has. Curiosity makes you ask these questions:

Which users are forking w3af?

This question is easy to answer by reading the network graph.

Which files are they changing?

It is possible to compare two repositories using Github's compare view

You can build the compare view URL manually with the following format: https://github.com/USER/REPO/compare/[USER:]GIT-REF…[USER:]GIT-REF. USER is your GitHub username, REPO is your GitHub repository, and GIT-REF can be a tag, branch, or commit SHA1. It’s also possible to do cross-repository compares by prepending another GitHub username to the git ref, with a colon dividing the username and git ref.

A couple of real-life examples:

• https://github.com/andresriancho/w3af/compare/andresriancho:threading2...tvelazquez:threading2
• https://github.com/andresriancho/w3af/compare/andresriancho:threading2...righettod:threading2

There are some problems with this approach, we don't know which branch they are working in (they might even create new branches), there might not be changes in the fork and we would be creating a compare view URL manually without knowing that.

I should create a python script that interacts with github's API to list all forks and then diff them using the git command and if there are any changes (or new branches) create a compare URL for me to review manually.

These are the commands for comparing the master branch of two different repositories, the original one which was already cloned and the one from the <username>:

git remote add <username>-fork git://github.com/<username>/w3af.git
git fetch <username>-fork
git diff origin/master <username>-fork/master

Keep in mind that this will only compare the master branch.

Why aren't they sending pull requests? How do I contact those users?

Some users have their emails listed in their github profile. I would recommend sending an email only if the changes they've made are really interesting.