CommitterResponsibilities

Timothy Lethbridge edited this page Jun 14, 2016 · 4 revisions
Clone this wiki locally

Introduction

In Umple, we follow a policy of making graduate students and a few other into committers once they have a history of successfully contributing. That means you can merge pull requests.

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 read the responsibilities below and remember to follow them from now on.

As a committer you must still contribute through pull requests. Unless urgent, have someone else review them. And always wait for a Travis build do complete before merging.

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 pull requests of others. We may ask you to review and commit specific pull requests.
  4. To ensure you have the right to contribute any code you are adding to Umple (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 added).
  5. To do git pull and resolve conficts before starting work each day, before commits and whenever anybody announces a change has been pushed to master.
  6. To keep your pull requests 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 making any pull request or merging any pull request to master, in order 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) git status to ensure you know you are contributing the correct files.
  10. To do a manual test of your code before creating a pull request or pulling into master (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 pull request (but not any generated code that would be replaced in any build).
  12. When you pull into master, to closely watch the build machines at Travis and at http://cc.umple.org and make sure the build passes. Builds are triggered a few minutes after each pull, but you can use the interface to manually trigger it faster than that. A build on the server takes about 4-6 minutes. If it goes 'red' (fails) you have to solve the problem (with another pull) before moving on to any other task. Often the matter is that you forgot to include a file. So don't pull 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 for a significant change, 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 change, ask others to review your pull request