This creates a p2 repository in org.eclipse.mylyn.reviews/releng/reviews-site/target/site

Documentation

TODO

Tests

TODO

Website

The Reviews website is located in a CVS repository on the Eclipse Foundation's servers.

File > Import > CVS > Projects from CVS

Select URL :pserver:anonymous@dev.eclipse.org/cvsroot/org.eclipse

Use module reviews (from www)

Finish

Contributing Patches

Granularity of Changes

Make small commits, as small as reasonable. This makes them easy to review.

Each commit should have a commit message that explains very clearly what the commit sets out to achieve (unless this is abundantly clear from the code itself, which is basically only the case for trivial patches). Also, when you fix a bug then report which bug you fix. When there are deeper reasons for doing things the way the commit does, then explain these as well. This all is for the reviewers and yourself: the context of the commit is completely clear.

Do not mix concerns in commits: have a commit do a single thing. This makes them reviewable 'in isolation'. The purpose of the commit is clear and can be understood easily by the reviewers and yourself.

Do not break the build and tests for any commit: this is very important for bug hunting.

Split your work into multiple smaller pieces of work (when possible) and implement each of these pieces in a series of commits.

A series of commits should work towards a 'feature' in a clear way and only 'enable' the feature in the last commit of the series.

In a series of commits first lay the groundwork and then build on that towards the feature.

Do not mix concerns in branches: when you encounter a bug while working on something then create a new branch to fix the bug. If your work depends on the bug being fixed then rebase your work on that new branch.

Commit message guidelines

The commit message header should fit on one line and should start with an uppercase letter

The commit message have newline characters after every 60-70 characters.

If there is an associated bug number in Bugzilla about it, it should come towards the end.

The first sentence should be a clear and concise description about the change.

Enter a newline before providing a more detailed description about the change.

Test before submitting

Run all existing tests. It does not take very long.

Sending patches by mail

Although sending patches by mail is the approved way of interacting with, and asking feedback from, the Git project, please don't send patches via git send-email. Instead, please use git format-patch to generate the mbox, and then attach that to an item in bugzilla as per the above SUBMITTING_PATCHES guides.

If you're sending a work-in-progress for a review, be aware that you can also attach work-in-progress (or RFC) items to Bugzilla; it's not just for finished patches.