Changes between Initial Version and Version 1 of CheckinPolicy


Ignore:
Timestamp:
08/20/10 16:18:13 (4 years ago)
Author:
dread
Comment:

First draft

Legend:

Unmodified
Added
Removed
Modified
  • CheckinPolicy

    v1 v1  
     1CKAN is open source and contributions are welcome. However, we have some guidelines for check-ins to ensure that all developers can work well together. 
     2 
     3 1. Work on the right branch - see VersionsAndBranching 
     4 1. Write tests for all changes. Unit tests go into ckan/tests/{area}/ and functional tests go into ckan/tests/functional/ . Tests describe intent and stop the code regressing in the future. 
     5 1. Run all the tests before you commit your code. It only takes 5 minutes 
     6 
     7Starting out: 
     8 * Before you can commit changes to the OKF repo, you'll need access rights - ask for these on [[CkanDiscuss|ckan-discuss]]. 
     9 
     10Life-cycle of a change: 
     11Unless it is a terribly minor change: 
     12 * Create a ticket with your suggestion and design detail as necessary 
     13 * Send a link to the ticket to [[CkanDiscuss|ckan-discuss]] and ask for suggestions 
     14 * Do it, whilst leaving the repo in a good state at all times (i.e. builds and works). Use another branch or bitbucket if necessary. 
     15 * Announce it on [[CkanDiscuss|ckan-discuss]] and close the ticket when done. 
     16 
     17Don't break the build: 
     18 * Keep an eye on [[http://buildbot.okfn.org/waterfall|buildbot]] to make sure you don't break the build. If you're a regular developer, ask to be added to the buildbot emails. Don't wait to be nagged by other frustrated developers ;-) 
     19 * If you break the build, please fix it quickly. If it may take time then email [[CkanDiscuss|ckan-discuss]] to let others know what the plan is.