Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Contributing to Koha


Published on

Proposed talk for the Helsinki Midwinter Darkness Camp 19th–20th January 2011. Meant to be a reminder about some of the important things to keep in mind when submitting code to the Koha project - and as an example of things to keep in mind when submitting code to any large free software project.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Contributing to Koha

  1. 1. Contributing to Koha Magnus Enger
  2. 2. Please note!● is the current website for the Koha project.● Avoid any and all sites at http://* - they are not updated according to the wishes of The Koha Community.
  3. 3. Many ways to contribute● Report bugs● Verify bugs● Fix bugs● Create new features/enhancements● Test and sign off on patches● Write documentation, add to the wiki● Translate● Answer questions on mail-lists and IRC● Etc, etc...
  4. 4. Hacking Koha!● Fixing bugs● Creating new features/enhancementsTwo guiding principles: ● Announce what you will work on ● Release early, release often
  5. 5. Bugzilla -● Always start by adding a bug report, both for bugs and enhancements
  6. 6. Wiki -● Creating an enhancement?● You should probably do an RFC on the wiki ● (Request For Comments) ● Unless its something really small ●
  7. 7. Start working!● Use the Git, Luke! ● Develop on a branch (named after your bug) ●● Publish your WIP (Work In Progress) ● In a public Git repository ●
  8. 8. ● git clone http://git.koha- kohaclone● cd kohaclone● git checkout -b mywork origin● Work, work, work ●
  9. 9. ● git add● git commit ● Use the bug number in the first line of the commit message● git format-patch origin● git send-email 0001-filename ●● Attach the patch to the bug in Bugzilla● Change the Importance of the bug to "Patch sent" and Patch Status to "Needs Signoff"
  10. 10. What happens next?● Someone must test and sign off on your patch and change the status to ● "Does not apply" or ● "Signed Off" ●● Then it is pushed to the main Koha Git repository, as a separate branch
  11. 11. And after that?● If the person in charge of QA is not happy with what you have done, Patch Status is changed to ● "Failed QA"● Otherwise, if the Release Manager too is happy with your work, the branch (patch) is merged into Koha and Patch Status is set to ● "Patch Pushed"
  12. 12. Youre not done yet, though!● Check that everything works as expected● Set the Status of the bug to "RESOLVED FIXED"● Congratulations!
  13. 13. Things to remember● Your patch should apply cleanly to the HEAD of master ● Rebase on master and resubmit your patch if changes in master makes the patch not apply any longer● If you have fixed a bug, it should also apply cleanly to the HEAD of the maintenance branch (currently 3.2.x) ● Submit a separate patch for 3.2.x if you have to
  14. 14. Happy hacking! Magnus