CommitterResponsibilities

FIXME

Introduction

In Umple, we follow a policy of making people committers once they have established a trustworthy history of having patches accepted.

Currently the project owners (primarily Dr. Lethbridge) choose who will be made committers. Once made a committer you are left in that state unless you request to have the status revoked, or you foul up a commit in a significant way (break the build or commit poor quality code) and don't immediately repair the damage, or are not active in Umple for over a year. However people who have made major contributions will normally remain permanently.

We will be requesting to become an Eclipse project; if this is approved, we would likely have to reduce the number of committers. Approval of new committers would then be done by vote of the other committers, and would require continuing committers to sign a form verifying that they have a right to commit everything they have and will commit; furthermore their employers will have to sign a form certifying that they don't object to having their employee be a committer.

When first made a committer

When first made a committer, you will need to

1. Read the responsibilities below and remember to follow them from now on.
2. Save any work you are currently working on as a patch (remember to svn add any added files first)
3. check out a new working directory to use as a committer. Go to https://code.google.com/p/umple/source/checkout and you will see a new command appears for you. The working set as a committer has certain slightly different svn attributes internally.
4. Apply the patch you saved in step 2 to the new working set, so you can continue work.

As a new committer you ought to practice patching rather than directly committing until you are certain of the process. To do this, finish the work you want to commit and create a patch. Then apply the patch to a separate fresh or updated working set and do a full build. If all tests pass (check the QA page) then you are likely to not break the build when you commit. You can then try committing. If in any doubt, you can still send a patch to another committer. But remember, one of the reasons for being a committer is to save other committers some time.

Responsibilities

Your responsibilities are:

1. To participate in project discussions on umple-dev where you have ideas, information or contributions that others have not mentioned, and to participate in any votes when asked (e.g. to admit new committers, or for making important architectural or process changes).
2. To consult with Dr Lethbridge and those on the umple-dev mailing list about design issues if you have any doubts about changes you are planning to make.
3. To help review the commits or patches of others. We may ask you to review and commit specific patches.
4. To ensure you have the right to commit contributions (e.g. you wrote the code, or the code has a license that is compatible with that of Umple -- No GPL-licensed code in particular can be committed).
5. To do svn update and resolve conficts before starting work each day, before commits and whenever anybody announces an update.
6. To keep your commits as small (agile) as reasonable.
7. To ensure you follow the test-driven development process; and to include tests at all needed levels in any commit.
8. To write efficient, well commented code that considers all necessary cases.
9. To do a full build (ant -Dmyenv=local) before any commit to be absolutely certain that it will work, then to do a) Check the qa page (dist/qa/ ) to ensure all tests have passed, and b) svn status to ensure you know you are committing the correct files, and svn add to add any new files before the commit.
10. To do a manual test of your code before a commit (not just to rely on the automated tests because they may be absent, commented out, etc.). You can do this using the command line version of the compiler you build that is found in the dist directory, or else using a local version of UmpleOnline (but in the latter case you need to deploy your changes to it)
11. To include all necessary files in the commit, including jet files and all generated code.
12. When you do a commit, to closely watch the build machine at http://cc.umple.org and make sure the build passes. Builds are triggered a few minutes after each commit, but you can use the interface to manually trigger it faster than that. A build on the server takes about 4 minutes. If it goes 'red' (fails) you have to solve the problem (with another commit) before moving on to any other task. Often the matter is that you forgot to include a file. So don't commit just before running off to do some other task, since we must not leave the build server in a 'broken' state, otherwise everybody else will update their svn with broken code.
13. Once the build on the server passes, announce the change to everybody at umple-dev, update the issue with a comment mentioning the revision number and status mostly-done, etc.. Don't mark the issue as 'verified' however. It is only project owners that do that after sufficient code review.

It is also suggested that if you have any doubt about a commit, that you instead first create a patch, and apply your patch to a different checked out working directory, and then following the above committing instructions from that (making doubly sure to re-do any svn add commands).